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This  document  was  prepared  by  the  Defense  Information  Systems  Agency,  Joint 
Interoperability  Engineering  Organization  (DISA/JIEO),  Center  for  Information  Management, 
sponsored  by  the  Office  of  the  Director  of  Defense  Information.  The  Software  Systems 
Engineering  Directorate,  Reengineering  Division  welcomes  any  comments  concerning  the 
contents  of  this  document. 
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EXECUTIVE  SUMMARY 


Knowing  when  to  reengineer  is  key  to  helping  managers  make  decisions  that  are  cost- 
effective  and  beneficial  to  reaching  their  (»ganizational  goals.  The  Sofbvare  Reoigineoing 
Criteria  provides  assistance  in  identifying  automated  informati<»i  systems  (AIS)  that  are 
candidates  for  reengineering  and  pn^)oses  how  software  reengineering  technology  can  benefit 
AIS.  Experiences  in  industry,  government  agencies,  and  academia  fostered  the  develt^nnent 
of  this  (Mteria  for  applying  software  reengineering  technology  to  information  sy^ems  by 
providing  guidelines  for  identifying  potential  candidates  for  reengineering.  The  Critaia 
provides  support  for 

(1)  predicting  the  return  on  investments  made  by  reengineering  existing  software 
systons,  and 

(2)  providing  the  business  case  for  achieving  the  highest  rate  of  return  from  software 
reengineering  technology. 


Reengineering  emeiges  as  a  strategy  for  bringing  the  cost  of  developing  and 
maintaining  software  undo:  control.  The  need  for  a  comprehensive  plan  to  achieve  goals,  set 
objectives,  develop  strategies,  and  t4)ply  reengineering  technology  is  the  driving  ftwce  in  many 
new  modernization  efforts  througihout  die  Department  of  Defense.  Determining  wfaidi 
software  system  can  benefit  from  reengineering  technology  and  how  it  will  benefit  is  the  first 
step  in  these  efforts.  The  Software  Reengineering  Criteria  will  assist  managers  facing  this 
situati<HL 

Ultimately t  the  process  of  software  reengineering  must  support  the  high-level  goals  of 
an  <»ganization,  which  include 

(1)  elimination  of  non-essential  products  and  processes, 

(2)  increasing  the  value  of  those  remaining;  and 

(3)  increasing  the  efficiency  of  those  processes  through  streamlining,  simplification 

and/or  automation  [Room92]. 


Two  broad  concepts  guide  software  reengineering  technology  development  in  the  DoD. 
The  first  is  the  preventitm  of  unnecessary  duplication  by  joint  use  of  personnel,  information 
systems,  facilities,  and  services  across  DoD.  The  second  concept  is  conformance  to  new 
regulations,  policies,  standards,  and  guidelines  for  software  acquisition  and  support.  Current 
practice  within  the  Federal  government  is  the  application  of  reengineering  to  perform  Pre¬ 
planned  Product  Improvement  (P^I)  efforts  or  modernize  software  systems  to  meet  new 
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standards.  These  standards  include  using  the  Ada  programming  language,  moving  towards 
open  software  systems,  and  maintaining  compliance  with  the  Portable  Operating  System 
Interface  Exchange  (POSIX).  Guidelines  include  integrating  Gjmmercial  OfF-the-Shelf 
(COTS)  whenever  possible,  including  Computer-Aided  Software  Engineering  (CASE)  into 
existing  software  engineering  environments. 

This  paper  summarizes  the  results  of  woiic  defining  a  criteria  for  idoitifying  automated 
information  systems  that  may  benefit  from  software  reengineering.  This  criteria  defines  the 
information  that  currently  serves  as  guidelines  for  making  this  determination.  Future  work 
will  apply  these  guidelines  to  establish  each  as  a  formal  criteria  for  identifying  information 
systems  as  candidates  for  software  reengineering. 

This  summary  presents  the  Software  Reengineering  Criteria  in  four  parts.  First,  a  set 
of  terms  defines  the  activities  within  reengineering  technology  (Section  2:  Definitions).  An 
overview  summarizes  other  sources  providing  guidance  for  when  to  reengineer  (Section  3: 
Existing  Guidance  for  Software  Reengineering).  The  Criteria  characterizes  software  systems 
and  software  engineering  environments  that  exhibit  the  potential  to  benefit  from  reengineering 
technology  and  presents  recommendations  for  software  reengineering  strategies  (Section  4: 
Software  Reengineering  Criteria).  Finally,  potential  application  areas  for  the  Criteria  are 
explored  (Section  5:  Application  Areas  for  Selection  Criteria). 

Until  recently,  various  terms  were  used  interchangeably  to  describe  the  activities  in 
software  reengineeting.  Industry,  government,  and  academia  are  achieving  a  consensus  on 
terminology  for  the  high-level  activities  within  software  reengineering  and  this  document 
presents  a  set  of  definitions  that  are  representative  of  this  consensus. 

Several  sources  define  guidance  for  determining  when  to  reengineer,  including  Federal 
agencies  and  others  working  in  the  commercial  arena.  This  guidance  lists  important  high- 
level  issues  to  consider  prior  to  software  reengineering,  but  does  not  discuss  how  the  specific 
characteristics  of  a  software  system  influence  the  decision  to  reengineer. 

The  Software  Reengineering  Criteria  defines  the  type  of  information  that  is  used  to 
identify  information  systems  as  potential  candidates  for  software  reengineering  and  determines 
how  reengineering  technology  can  benefit  computer  software  systems.  The  Criteria  is 
composed  of  two  categories:  those  that  deal  with  the  existing  software  system(s)  and  those 
that  are  desired  in  the  reengineered  software  system.  Existing  Software  System  Criteria 
characterize  existing  software  system(s),  the  environment  in  which  it  operates,  and  the  process 
by  which  it  was  developed  and  is  currently  maintained.  Reengineeted  Software  System 
Criteria  characterize  the  target  software,  the  new  support  environment,  the  new  operation 
environment,  and  the  factors  which  influence  the  software  reengineering  process. 

The  Software  Reengineering  Criteria  was  developed  using  data  gathered  from 
completed  reengineering  projects.  To  date  there  is  little  documented  experience  estimating 
the  effort  involved  in  software  reengineering.  As  experience  builds,  so  will  the  understanding 
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of  how  sofhvare  reengineering  should  be  perfonned.  This  document  serves  as  the  basis  for 
such  guidance  and  provides  information  that  will  benefit  oiganizations  considering  software 
reengineering  technology. 
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1.  INTRODUCTION 


The  Software  Reengineering  Criteria  provides  assistance  in  identifying  automated 
information  systems  (AlSs)  that  are  candidates  for  reengineering  and  proposes  how 
reengineering  technology  can  benefit  these  information  systems.  Knowing  when  to  reengineer 
is  key  to  helping  managers  make  decisions  that  are  cost-effective  and  beneficid  to  reaching 
their  organizational  goals.  Experiences  in  industry,  government  agencies,  and  academia  were 
used  to  develop  this  Criteria  for  selecting  software  systems  to  reengineer.  The  Criteria  should 
be  supplemented  by  cost/benefit  analysis  for  determining  whether  reengineering  is  an 
^propriate  means  for  modernizing  software  systems  in  a  given  enviromnent.  The  Criteria 
assists  in  predicting  the  return  on  investments  made  by  reengineering  existing  software 
systems,  and  supports  the  development  of  the  business  case  for  achieving  the  hipest  rate  of 
return  from  reengineering  technology. 


1.1  Scope 

The  Software  Reengineering  Criteria  addresses  information  systems,  primarily  those 
within  the  Dq>artment  of  Defense  (DoD)  and  its  jurisdictions.  These  software  systems  are 
data-intensive,  often  interacting  witii  a  database,  perform  many  processes  in  batch  mode,  and 
arc  concerned  with  report  generation.  The  term  "software"  will  be  used  throughout  this 
document  to  refer  to  Ae  source  code  programs  implemented  to  meet  requirements  of  a  given 
information  system.  The  "software  system"  will  refer  to  this  software,  excluding  any 
Commercial  Off-the-Shelf  (COTS)  products  with  which  this  software  integrates  to  ftilfill  the 
overall  requirements  of  the  information  system.  The  software  system  does  not  include  the 
hardware  platform  on  which  these  components  execute;  the  hardware  suite  is  considered  part 
of  the  operational  environment 

This  pq)er  summarizes  the  results  of  work  defining  a  criteria  for  identifying  automated 
information  systems  that  benefit  fiom  software  reengineering.  Data  gatiiered  from  completed 
reengineering  projects  [Hobb91,  MITR92,  Ruhl91]  supported  the  development  of  the  Criteria 
which  recommends  a  reengineering  strategy  utilizing  reverse  engineering,  restructuring, 
redocumentation,  translation,  and  software  reuse.  These  initial  results  succeed  in  identifying 
potential  criteria  that  currently  serve  as  guidelines  for  making  this  determination,  future  work 
will  apply  these  guidelines  for  verifying  each  as  a  measurable  criteria  for  applying  software 
reengineering. 

This  paper  presents  the  Software  Reengineering  Criteria  in  four  parts.  First,  a  set  of 
terms  for  defining  software  reengineering  activities  is  presented  (Section  2:  Definitions).  An 
overview  of  other  sources  that  have  provided  guidance  for  when  to  reengineer  is  summarized 
(Section  3:  Existing  Guidance  for  Reengineering).  The  Criteria  is  then  presented  along  with 
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guidance  for  how  data  collected  using  the  Criteria  is  used  to  determine  how  and  when  to 
reengineer  (Section  4;  Software  Reengineering  Criteria).  This  guidance  is  based  on  key 
practices  within  software  engineering  applicable  to  most  organizations  and  therefore  is  not 
dependent  on  an  organization's  maturity.  Finally,  potential  application  areas  for  the  Criteria 
are  explored  (Section  5:  Application  Areas  for  Selection  Criteria). 


1.2  Motivation 

The  Defense  Information  Systems  Agency,  Center  for  Information  Management  (DISA/CIM) 
has  the  mission  of  providing  information  management  technical  services  to  the  DoD 
community.  The  DISA/CIM  Software  Systems  Engineering  Directorate  is  responsible  for 
assessing  and  promoting  current  leengineeiing  technology  in  DoD  modernization  efforts.  The 
Software  Reengineering  Assistance  Program  has  been  established  by  the  directorate  to  meet 
this  objective.  This  Program  uses  experiences  in  industry,  government  agencies,  and 
academia  to  develop  the  Criteria  for  selecting  software  systems  to  reengineer. 

The  DoD  Information  Management  (IM)  community  has  approximately  1.4  billion 
lines  of  operational  software  today.  Many  of  these  systems  were  developed  prior  to  the 
availability  of  modem  technologies,  including  methods,  languages,  and  automation.  The  CIM 
initiative  for  reducing  the  number  of  software  systems  across  functional  domains  and 
eliminating  redundancy,  has  generated  a  strong  need  to  modernize  these  systems.  This 
modernization  is  supported  by  software  reengineering  strategies  that  minimize  development 
costs,  reduce  maintenance  expenses,  and  lev^ge  existing  software  assets.  To  this  end,  the 
Criteria  will  support  the  choice  of  information  systems  that  will  benefit  from  reengineering. 

Reengineering  is  used  in  Pre-plaimed  Product  Improvement  (Fl)  efforts  or  modernize 
software  systons  to  meet  new  standards.  These  standards  include  MIL-STD-181SA,  Ada 
Programming  Language;  FIPS  146-2,  Government  Open-Systems  Interconnection  Protocol; 
and  FIPS  lSl-1,  Portable  Operating  System  Interface  Exchange  (POSIX).  Reengineering  is 
also  used  to  in^rove  the  maintenance  of  existing  software  systems,  by  integrating  Con^uter- 
aided  Software  Engineering  (CASE)  into  the  existing  software  engineering  environments.  The 
Software  Reengineering  Criteria  will  assist  those  managers  feced  with  these  situations. 
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2.  DEFlNmONS 


A  set  of  definitions'  for  terms  used  to  describe  the  activities  within  software 
reengineering  is  presented  in  the  following  section  (Appendix  A  GLOSSARY  OF  TERMS). 
Until  recently,  the  capabilities  of  reengineering  were  so  tightly  intertwined  that  these  terms 
were  often  used  intochangeably.  However,  there  are  unique  qualities  in  these  activities  ^ch 
distinguish  them  from  cme  anoAer,  and  these  qualities  form  the  distinction  for  each  definition. 
Industry,  government,  and  academia  have  begun  to  reach  a  consensus  on  the  major  toms  in 
software  reengineering  and  this  document  presents  a  set  of  definitions  that  are  rejn^soitative 
of  this  ctmsensus. 

Software  reengineering  activities  are  distinct  in  two  ways:  (1)  the  objects  acted  upcm 
during  the  activity  and  (2)  the  products  that  are  produced  as  a  result  of  doing  this  activity 
(Figure  2-1).  In  addition,  the  terms  have  specific  primary  objectives  that  are  the  goal  of  each 
activity  and  diere  are  other  issues  that  distinguish  each  activity  from  the  others. 


2.1  Definitions  of  Terms 


2.1.1  Software  Reengineering.  The  examination  and  alteration  of  an  informarion  system  to 
reconstitute  it  in  a  new  form.  The  process  enconq)asses  a  combination  of  other  processes 
such  as  reverse  engineering,  restructuring,  forward  engineering,  redocumentation,  and 
translation.  The  goal  is  to  ii]:q)rove  the  software  system  (functionality,  performance,  or 
inq)lementation).  The  distinction  is  that  additional  flmctionality  is  often  incorporated  into  the 
system  during  ^s  process  [Kerr91,  Perr92]. 


2.1.2  Reverse  Engineering.  The  process  of  examining  an  information  system  by  analyzing  its 
documentation,  {q)plication  softvme,  and  data  structures  within  the  environment  in  v^Mch  the 
information  system  operates.  This  analysis  is  poformed  to  (1)  identify  die  system's 
conqxments  and  their  interrelationships,  and  (2)  create  representations  of  the  system  in 
another  form  or  at  a  higher  level  of  ^straction.  The  god  is  to  understand  the  existing 
software  system  (functions,  performance,  or  irrqilementation).  Extracted  information  is 
represented  in  a  format  which  can  be  integrated  into  the  life  cycle  for  development  of  a 
software  system  [Kerr91,  Perr92]. 


'  The  definitions  for  reengineering,  redocumentation,  and  restructuring  are  variations  of  the  definitions 
originally  presented  by  Chikofsky  and  Cross  [Chik90]. 


2.1.3  Restructuring  The  transformation  of  a  software  system  from  one  representation  form  to 
another  at  the  same  relative  abstraction  level,  while  preserving  the  system's  external  behavior 
(functionality  and  semantics).  The  goal  is  to  improve  a  representation  of  the  existing  software 
system.  The  distinction  is  that  restructured  systems  are  functionally  equivalent  to  the  existing 
system,  but  should  be  easier  to  support  [Ken91]. 


2.1.4  Forward  Engineering.  Within  the  context  of  reengineering,  forward  engineering  is  the 
software  engineering  activities  that  consume  the  products  of  reengineering  activities  primarily 
reverse  engineering,  reuse,  and  new  requirements  to  produce  a  target  system.  The  goal  is  to 
create  a  software  system  via  reengineering.  This  term  primarily  refers  to  the  process  of 
generating  new  software  systems  from  reverse  engineer^  designs.  This  term  has  evolved 
within  reengineering  to  refer  to  those  software  engineering  activities  (traditionally  performed 
during  development)  that  are  performed  during  or  as  a  result  of  reengineering. 


2.1.5  Redocumentation.  The  creation  or  revision  of  a  semantically  equivalent  representation 
with  the  same  relative  abstraction  level.  The  goal  is  to  understand  a  given  representation  of 
the  existing  software  system  (whether  it  be  a  specification,  design,  or  implementation).  The 
distinction  is  that  diis  activity  does  not  alter  the  existing  software  system  representation,  nor 
does  it  generate  any  new  representation  to  replace  any  part  of  the  existing  representation. 
Redocumentation  produces  supplementary  information  that  provides  understanding  of  tiie 
existing  systan  and  its  sub-parts.  This  activity  is  usually  p^oimed  to  assist  in  maintenance 
of  existing  system. 


2.1.6  Translation.  Transformation  of  source  code  from  one  language  to  another  or  from  one 
version  of  a  language  to  another  version  of  the  same  language.  The  goal  is  to  irrq)rove  the 
linguistic  inqrlementation  of  the  software.  This  process  is  most  successfiil  when  the  two 
languages  are  similar  or  have  a  defined  mapping  between  syntax. 


2.1.7  Software  Reuse.  The  application  of  existing  software  work  products,  including  source 
code,  documentation,  designs,  test  data,  tools,  and  specifications,  in  a  software  development 
effort  other  than  the  one  for  which  each  was  originally  developed.  The  goal  is  to  facilitate 
the  return  on  investment  (ROI);  improve  software  quality  and  reliability;  shorten  system 
development  and  maintenance  times;  increase  productivity  and  minimize  software-related 
risks.  Software  reuse  should  be  employed  diuing  reengineering  and  reengineering  should  be 
applied  to  identify  candidate  reusable  assets. 
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1  Term 

object 

product 

Goal 

1  Forward  Engineering 

reverse  engineered 
design 

software 

generate  software 
system  from  reverse 
engineered  products 

Reengineering 

existing  software 

new  software 

improve  software 
system 

1  Reverse  Engineering 

existing  software 

reverse  engineered 
design 

understand  software 
system;  prepare  for 
development  of 
replacement  system 

1  Restructuring 

existing  software 

improved  existing 

software 

representation 

improve  a  given 
representation  of 
software  system 

Redocumentation 

uses  software,  existing 
documentation,  and 
available  expertise 

supplemental 

documentation 

understand  software 
system;  maintain 
existing  system 

Software  Reuse 

software  assets 

software  component 
(new  context) 

ROI,  eliminate 
redundancy 

Translation 

existing  source  code  or 
design  language 

new  source  or  design 
code  in  alternate 
language 

improve  source  code 
or  design  code 

FIGURE  2<1.  Comparison  of  Software  Reengineering  Activities. 


2.2  Interfaces  Between  Reengineering  Activities 

The  definitions  above  suggest  strong  relationships  between  terms  which  need 
clarification.  These  relationships  are  (1)  reverse  engineering  and  redocumentation  and  (2) 
restructuring  and  reengineeting. 


2.2.1  Reverse  engineering  and  Redocumentation.  Software  reverse  engineering  and 
redocumentation  have  the  goal  to  provide  understanding  of  the  existing  software  system.  The 
differences  between  these  capabilities  are  the  end  product  and  the  underlying  motivation  for 
this  activity.  Reverse  engineering  generates  a  product  that  could  potentially  serve  as  a  design 
or  specification  for  the  generation  of  new  software.  Redocumenting  software  produces 
supplementary  reference  material  that  explains  a  given  representation  of  the  software  system, 
whether  it  be  design  or  implementation.  Reverse  engineering  most  often  results  in  a  more 
comprehensive  view  of  the  software.  Documentation  usually  explains  a  specific  aspect  of  the 
software  system  in  further  detail. 
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2.2.2  Restructuring  and  Reengineering.  Restructuring  and  reengineering  both  improve  the 
sofrivare  system,  but  restructuring  is  limited  to  the  nuxlification  of  a  current  representation  of 
the  system  code  which  will  replace  the  existing  representation,  without  introducing  new 
functionality,  or  implementation  characteristics  (i.e.,  programming  language).  Reengineering 
often  includes  flmctional  alterations  and  often  succeeds  in  generating  a  completely  new 
in^lementation  of  the  software  in  a  new  programming  language. 


23  Reengineering  Process 

The  reengineering  process  often  consists  of  several  activities  when  it  is  applied  to  a 
software  system  (Figure  2-2).  A  data  flow  diagram  is  a  useful  format  for  representing  the 
reladon^p  between  reengineering  activities  (Figure  2-3)  relative  to  the  data  shared  by  each 
activity. 
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FIGURE  2-2. 


REOOCUMENT 


REPOSITORIES 


3.  EXISTING  GUIDANCE  FOR  REENGINEERING 


Existing  guidance  ftH*  detomining  when  to  reengineer  has  been  defined  by  the 
Software  Technolt^  Stq>pQrt  Center  (STSQ  [Sitt92b],  the  Joint  Logistic  Commanders  (JLC) 
Santa  Barbara  I  Workshop  [JLC92],  the  Natitmal  Institute  of  Standards  and  Technology 
(NIST)  [Ruhl91],  and  by  others  working  in  the  ctxnmercial  aroia  [KetT91,  Perr92].  This 
guidance  lists  important  high-level  issues  to  consider  prior  to  reengineering  and  provides 
assistance  in  determining  >^iat  type  of  reengineering  should  be  performed  <m  a  candidate 
software  system.  It  has  also  bem  suggested  that  there  is  a  close  link  between  software  reuse 
and  reengineering  [Stev92].  This  guidance  does  not  discuss  how  the  specific  characteristics 
of  a  software  tystem  influence  the  decision  to  reengineer  ntn*  does  it  discuss  the  trade-offii  for 
differing  reengineering  strategies.  Mtne  detailed  summaries  of  this  guidance  ate  discussed  in 
Appendix  B  EXISTING  REENGINEERING  GUIDANCE  SOURCES.  A  brief  summary  of 
each  source  is  presoited  below. 


3.1  STSCs  Reengineering  Candidate  Selectitm  Process 

The  STSCs  Reengineering  Candidate  Selection  Process  is  a  common-sense  approach 
to  determining  the  most  appropriate  reengineering  nMthodology  to  perform  (e.g.,  restructure, 
reverse  engineer,  redocument).  The  process  is  based  on  a  set  of  weighted  questions  that  are 
dq>endent  on  three  variables  describing  the  software:  conq)lexity,  inq)ortance,  and  longevity 
[Sitt92b,  p24]. 


3.2  Joint  Logistic  Commanders  Santa  Barbara  I  Workshop 

The  JLC  Joint  Policy  Coordinating  Group  on  Computer  Resources  Management 
(CRM)  qxHisored  the  First  Software  Reengineering  Wcnkshop:  Santa  Barbara  I  on  September 
21-25,  1992  in  Santa  Barbara,  California.  Santa  Barbara  I  brought  together  members  of 
Government,  Industry,  and  Academia  to  define  reengineering  technology  and  determine  die 
impact  of  reengineering  on  software  acquisititm  policies.  The  Proceedings  of  Santa  Barbara  1 
contains  a  list  of  the  nx>st  critical  criteria  for  detomining  vriien  to  reengineer  (Appoidix  B) 
[JLC92].  Examples  of  this  criteria  include  Technical  Quality,  Life-Cycle  Remaining,  and 
Maturity  Level.  This  criteria  includes  important  issues  to  consider  prior  to  reengineering,  but 
does  not  provide  direction  as  to  What  reengineering  strategy  to  follow. 

A  draft  Reengineaing  Economics  Handbook  (MIL-HDBK-REH)  was  developed 
during  Santa  Barbara  I  [REH92].  This  handbook  defines  a  Reengineering  Decision-Making 
Process  that  is  based  on  the  STSCs  Reengineering  Candidate  Selection  Process.  The  MIL- 
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HDBK-REH  is  in  draft  form  and  will  evolve  as  part  of  the  on-going  Santa  Barbara  I  effort. 
The  objective  of  the  handbook  is  to  assist  in  deciding  whether  a  software  system  should  (1) 
be  maintained  at  a  similar  level  of  effort,  (2)  reengineered  to  change,  modify,  or  improve  the 
software,  or  (3)  replace  the  current  software  with  a  completely  new  system. 


3.3  NIST  Variables  for  Reengineoing  Effectiveness 

A  NIST  study  poformed  in  1991  concluded  that  the  effectiveness  of  reengineering  is 
dependent  on  three  variables  [Ruhl91,  pl4]:  (1)  corporate  and  system  goals;  (2)  condition  of 
the  current  application  and  documentation;  and  (3)  available  resources  (tools  and  po'sonnel). 
A  few  of  the  lecommoidations  \^ch  resulted  from  diis  study  include  the  following  [Ruhl91, 
pl6-23]: 

When  procuring  equipment,  require  conformance  to  applicable  standards  (e.g.,  FIPS)  to 
achieve  flexibility  and  ease  in  future  migrations. 

While  design  recovery  is  difficult,  time-consuming,  and  essentially  a  manual  process,  it  is 
vital  for  recovering  lost  information  and  information  transfer. 

Provisicms  in  terms  of  persormel  and  effort  must  be  made  to  corrqpensate  for  the  lack  of 
full  support  of  the  reengineering  process  by  currently  available  off-the-shelf  tools. 

Adequate  storage  capacity  and  processor  q)eed  in  equipment  supporting  the  remginemng 
tools  are  essential  to  facilitate  the  reengineering  process. 

It  is  critical  that  the  application  system  experts  be  involved  throughout  the  reengineering 
process.  They  are  essential  for  design  recovery. 


3.4  Other  Guidance  Sources 

Other  recommendations  for  determining  when  a  software  system  is  applicable  for 
reengineeting  have  been  defined  by  industry  representatives  in  recent  literary  articles  [Ken91, 
PeiT92].  These  recommaidations  provide  genoal  guidance  that  is  useful  >^en  deciding  wdien 
to  reengineer,  but  are  highly  intuitive  and  do  not  provide  any  indications  as  to  how  the  status 
of  a  candidate  application  impacts  the  success  of  the  reengineering  process. 

Kerr  and  McGovern  consider  reengineering  as  part  of  the  maintenance  process 
[Kerr91].  Candidate  applications  are  categorized  into  three  types  of  systems  based  on  levels 
of  importance  (this  is  similar  to  the  STSC  Process).  High  importance  applications  should  be 
reverse  engineered  to  inq)rove  quality  and  ease  maintenance.  Applications  of  medium 
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importance  should  be  reengineered,  during  which  other  applications  of  similar  importance  are 
combined  to  justify  resources  necessary  to  perform  this  activity  and  consolidate  systems,  thus 
minimizing  resources  for  more  than  one  system.  Applications  that  are  not  important  should 
be  left  alone,  assuming  that  the  resources  necessary  for  reengineering  these  systems  are  not 
worth  the  benefits. 

Perry  defines  reengineeiing  activities  within  the  scope  of  downsizing  from  mainframe 
to  microcomputer  platforms.  Since  most  object-oriented  modeling,  CASE,  and  reengineering 
tool  support  is  av^lable  on  workstations,  downsizing  is  often  intrinsic  to  the  reengineering 
process  selected.  Downsizing  begins  with  a  three-step  process,  starting  with  the  selection  of 
the  appropriate  ^plication,  component  analysis  for  partial-downsizing,  and  finally  die 
determination  of  a  technique  for  downsizing.  These  techniques  include  using  a  ccnmnercial 
packaged  environment  that  enables  the  microconqiuter  to  perform  like  a  mainframe,  in  \(duch 
case  the  application  should  be  able  to  execute  in  its  misting  form.  The  other  three  techniques 
include  restructuring,  reengineering,  and  reverse  engineering. 


3.5  Conclusions 

The  STSC  process  provides  useful  guidelines  for  determining  a  reengineering  option 
for  a  candidate  software  system.  The  NIST  goal  variables  must  also  be  considered  in  order  to 
predict  the  success  of  the  reengineering.  The  Software  Reengineering  Criteria  considers  the 
characteristics  of  the  existing  software  system  and  the  desired  target  system,  the  available 
reengineering  technology,  as  well  as  the  inqiact  of  such  issues  as  those  defined  by  the  NIST 
goal  variables. 
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4.  SOFTWARE  REENGINEERING  CRITERIA 


The  Software  Reengineering  Criteria  provides  insight  into  the  benefits  of  reengjnemng 
technology.  The  Criteria  is  c(Hiq>osed  of  two  categories:  critma  that  describe  the  existing 
software  systein(s)  and  criteria  defined  by  reengineering  technology  (Figure  4-1).  Existing 
Software  System  Criteria  characterize  the  existing  software  system,  the  environment  in  vv^iich 
it  operates,  and  die  process  by  wliich  it  was  developed  and  is  currently  maintained. 
Reengineered  Software  System  Criteria  characterize  target  software  systems,  new  siqiport 
environments,  new  operational  environments,  and  the  factors  which  influence  the 
reengineeiing  process. 


FIGURE  4-1.  Software  Reengineerin?  Criteria  Categories. 


The  Software  Reengineering  Criteria  can  be  used  in  several  ways.  The  Criteria  can  be 
applied  to  either  a  specific  software  system  or  an  entire  software  engineering  environment. 

An  individual  criteria  can  also  be  examined  for  its  impact  on  applying  reengineering 
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technology.  For  example,  the  impact  of  available  design  information  when  reengineering  can 
be  examined  by  looking  up  the  criteria  called  E)esign. 

The  Criteria  should  be  measured  numerically  where  possible,  otherwise  documented  in 
ccmcise,  easily  understood  terms.  It  is  in^rtant  to  be  consistent  whoi  applying  the  Criteria 
across  multiple  software  systems  and  to  be  aware  of  the  differences  in  units  of  measurements 
when  conqKuing  external  data. 

Each  of  the  criteria  is  defined  in  terms  of  product  and  process^.  A  tabular  listing  of 
the  Criteria  is  located  in  Appendix  D  SOFTWARE  REENGINEERING  CRITERIA  TABLES. 
The  in^>act  of  each  criteria  on  reengineering  is  discussed,  including  a  description  of  the 
reengineering  strategy  that  is  recommended  given  that  certain  criteria  is  met 


4.1  Existing  Software  System  Criteria 

Existing  Software  System  Criteria  is  composed  of  product  characteristics  that  describe 
the  existing  software  system,  the  environment  in  which  it  operates,  and  process  factors  vriiich 
influenced  the  developmoit  and  maintenance  of  the  system. 


4.1.1  Product  Qiaracteristics.  Product  characteristics  describe  the  software  system,  including 
software  characteristics  and  system  characteristics,  and  the  characteristics  describing  the 
envirmunent  in  which  this  system  operates. 

4.1.1.1  Software  Characteristics.  Software  characteristics  describe  the  source  code  of  the 
systenL  Several  authors  have  defined  software  characteristics  which  inq)act  reengineering 
(maintenance)  [BoehSl,  NIST,  Sitt92a,  Sitt92b].  The  Software  Characteristics  Criteria  are 
defined  below. 

Software  Characteristics  Description 

Complexity  software  constructs  (conditionals,  iterations. 

statements),  caiis  to  external  routines,  and  I/O 

Data  structure  variables,  constants,  complex  structures  (records. 

linked  lists),  user-defined  constructs 

Languages  number  of  implementation  languages  and  defined 

grammars  for  each 


^  Product  criteria  are  referred  to  as  characteristics,  since  this  criteria  usually  describes  an  attribute  of  the 
software  or  its  environment.  Process  criteria  are  called  factors  since  this  criteria  influence  the  activities  of 
developing,  maintaining,  and  reengineering. 
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defined,  unique  functionality  in  each  module 

SLOG,  function  points,  number  of  modules/objects, 
bytes,  number  of  files 

average  number  of  modifications,  both  corrective  and 
perfective,  over  a  given  period  of  time 

Number  of  times  this  software  is  accessed  in  a  given 
period  of  time;  is  the  software  functionality  life- 
threatening;  does  the  software  perform  some 
function(s)  not  performed  anywhere  else  in  the 
organization? 

Structural  quality  an  analysis  of  the  structure  of  the  software  system,  i.e, 

missing  code,  code  that  is  never  executed;  evidence  of 
work-arounds. 


Modularity 

Size 

Software  change  rate 
Software  importance 


Complexity  describes  the  software  constructs  (conditionals,  iterations,  statements),  calls  to 
external  routines,  and  I/O.  There  are  several  methods  for  calculating  software  complexity, 
including  McCabe  Cyclomatic  Con:q>lexity^.  Restructuring  the  existing  software  may  lessen 
the  crm^lexity  without  altering  the  ftmctionality  of  the  software.  Emphasis  should  be  placed 
on  eliminating  "goto**  statements  and  code  that  is  never  executed.  The  software  can  also  be 
reverse  engineered  to  a  high-level  design  which  is  then  restructured  and  used  to  generate  a 
more  concise  and  efficient  in^lementation  of  the  software.  The  reverse  engineering  process 
must  be  verified  to  insure  that  the  recovered  design  accurately  captures  the  existing  software. 
This  process  is  preferred  when  there  are  additional  implementation  changes  desired,  such  as 
converting  to  the  Ada  programming  language. 

Data  structure  describes  the  variables,  constants,  complex  structures  (records,  linked  lists),  and 
user-defined  constructs  in  which  data  is  stored  in  the  software.  It  also  includes  the  naming 
conventions  utilized  in  the  original  software  implementation.  Data  design  is  the  key  structural 
component  in  most  information  systems,  requiring  extensive  database  management  The 
largest  percent  of  ftmctionality  in  most  information  systems  is  performed  within  the  context  of 
data  management  The  data  architecture  is  often  the  driving  force  behind  the  software  control 
fiow  architecture.  For  this  reason,  emphasis  should  be  placed  on  the  data  design  because  it 
will  force  modifications  to  the  process  design  [Ruhl91,  pi  7].  Redocumentation  may  provide 
insight  into  the  current  structure  of  the  data,  generating  tables  of  variable  names,  and 
identifying  within  the  software  where  the  data  is  used  and  modified.  Steps  should  be  taken  to 
rename  data  to  more  informative  terms  as  permitted  in  the  current  software  implementation 
[MITR92]  and  to  adhere  to  DoD  standards  concerning  data  naming  conventions.  Reverse 
engineering  the  data  model  and  integrating  an  efficient  data  management  facility  will  provide 
the  biggest  payoff  for  most  information  systems  [MITR92].  Improved  naming  conventions 


’  McCabe,  Thomas  J,  "A  Complexity  Measure,"  IEEE  Transactions  on  Software  Engineering,  December 
1976,  pp.  308-320. 
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may  only  be  achieved  by  reimplementing  in  a  new  programming  language,  such  as  a  language 
that  does  not  limit  variable  name  length  or  characters  that  can  be  used.  Migration  to 
advanced  hardware  platforms  also  can  improve  data  structure  and  naming  conventions  through 
increased  memory  opacity. 

Languages  describe  the  programming  languages  used  to  inclement  the  software.  For  many 
information  systems  the  COBOL  programming  language  was  used  and  sometimes  a  hardware- 
dependent  assembly  language.  The  functions  of  many  infcamation  systems  are  limited  in 
numbo'  and  are  repeated  throughout  all  similar  software  systems.  There  are  many  automated 
translation  tools  which  can  be  used  to  convert  COBOL-based  programs  to  new 
implementation  languages.  Translation  is  usually  most  successful  in  efforts  where  the  goal  is 
to  solely  generate  a  new  version  of  the  system  in  another  language  that  is  similar  to  the 
current  language  or  a  different  version  of  the  same  language.  A  translation  strategy  is  most 
successful  with  small  programs  where  the  software  architecture  and  data  stracture  will  remain 
the  same.  Reverse  engineering  to  a  language-independent  design  is  an  alternative  to 
translation  which  may  be  more  time-omsuming  and  expensive.  This  design  can  then  be  used 
to  generate  a  more  efficient  representation  of  tire  software,  taking  advantage  of  the  new 
language  constructs.  Translation  does  not  incorporate  alternative  implementations  which  use 
the  unique  features  of  the  target  language.  This  must  be  acconq)lished  through  manual 
convosion  or  restructuring  techniques. 

Modularity  refers  to  the  ability  to  identify  and  isolate  unique  functionality  within  tiie  software. 
An  organization  should  examine  all  software  systems  that  it  maintains  for  fimctional 
commonality  and  consider  eliminating  redundancy  and  minimizing  maintenance  by  combining 
functionality  into  single  systems.  Each  application  system  should  be  evaluated  with  the  intent 
of  discovering  what  is  worth  retaining  for  future  use  and  what  is  not  [Ruhl91,  pl7]. 
Organizations  need  to  identify  the  inqwrtant  functions  within  software  systems  that  should  be 
maintained  as  legacy.  The  designs  and  mq)lementations  of  these  requirements  should  be 
isolated  and  examined  for  potential  software  reuse.  The  iiiq)lementations  can  be  reverse 
engineered  to  capture  the  design  for  future  use.  Implementations  that  serve  inq>ortant 
functions  may  be  restructured  to  achieve  the  optimal  implementation  for  multiple  use.  AU  of 
these  conqxments  should  be  well-documented. 

Size  defines  the  voliune  of  the  software  in  some  standard  unit  of  measure.  There  are  several 
sources  for  measuring  the  size  of  software  systems,  including  Albrecht  and  Gaffney^  and  the 
Software  Engineering  Institute  (SEI).  The  most  common  measurement  is  source  lines  of  code 
(SLOQ,  although  critics  argue  as  to  its  usefulness  in  software  planning  and  control  [Keme93, 
p87].  Function  points  are  another  unit  of  measure  that  delineates  size  through  specifying 
functions  which  the  software  performs  as  a  way  of  measuring  the  magnitude  of  the  software. 
Other  units  of  measure  that  have  been  proposed  include  number  of  modules,  objects,  bytes, 
and  number  of  files.  Consistent  measurements  and  the  ability  to  adjust  to  other  defined  units 


*  Albrecht,  A.,  and  J.  Gaffney,  "Software  Function,  Source  Lines  of  Code,  and  Develq)ment  Effort 
Prediction,"  IEEE  Transactions  on  Software  Engineering,  vol  SE-9,  no.  6,  November  1983,  pp.  639-648. 
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of  measure  is  the  most  in^rtant  issue  when  comparing  data.  Cost  and  schedule  will  also  be 
impacted  by  the  size.  In  general,  reengineering  processes  that  are  easy  to  automate  will  be 
more  successful  on  smaller  software  modules.  More  manual  efforts  will  be  required  on  larger 
modules. 

Software  change  rate  describes  the  average  number  of  modifications,  both  corrective  and 
perfective,  performed  on  a  software  system  during  a  given  period  of  time.  This  rate  is  often 
indicative  of  the  number  of  defects  in  the  software,  or  may  reflect  the  variety  and  volume  of 
users.  Assessments  should  be  made  to  determine  what  the  needs  of  the  user  are  relative  to 
the  functionality  of  the  software.  An  ever-changing  software  system  should  be  quickly 
migrated  to  a  more  efficient  support  envirorunent  to  better  adapt  to  the  needs  of  the  user. 
Urmecessary  functionality  should  be  eliminated,  and  desired  functionality  improved.  Reverse 
engineering  to  a  Con:q)uter-aided  software  engin^ring  (CASE)  environment  can  provide 
automated  support  and  is  also  useful  generating  a  more  modem  system. 

Software  importance  is  determined  by  the  number  of  people  or  organizations  which  utilize  the 
software  system.  Users  of  the  system  also  include  external  automated  systems  with  vdiich  the 
candidate  system  interfaces.  Examples  of  hig)ily  critical  software  systems  include  those  that 
poform  functions  in  no  otho*  software  system,  those  which  could  not  easily  be  replaced  with 
another  system,  and  those  which  would  ^ve  a  detrimental  effect  on  the  organization  if  they 
were  to  be  eliminated.  A  payroll  system  could  be  considered  a  highly  critical  system,  since 
its  elimination  would  have  an  enormous  impact  on  the  organization  ^ould  the  employees 
experience  a  delay  in  their  pay.  If  the  system  performs  hfe-threatening  functions  or  unique 
functions  which  no  other  system  performs,  then  the  system  is  also  highly  critical.  Information 
dependencies  between  the  candidate  system  and  external  systems,  as  well  as  other  systenrs 
within  a  like  domain  should  be  identified  [Ruhl91,  plS].  The  organization  should  make  a 
determinatirm  as  to  why  the  system  is  inqrortant  and  consider  redevelopment  or  reverse 
engineeting,  while  the  system  remains  in  use.  This  system  should  probably  be  an  example 
system  to  analyze  from  a  functional  viewpoint  as  a  basis  for  determining  new  technology  that 
will  in^rove  the  overall  current  business  practices  of  the  organization  [Ruhl91,  plS].  The 
cost  of  reengineering  these  systems  should  be  weighed  heavily  against  the  importance  of  its 
functions  and  ample  support  should  be  given  to  improve  and  secure  this  type  of  software 
system  for  extended  use.  Highly  critical  systems  shotrld  be  further  examined  for 
consolidation  to  minimize  the  number  of  overall  systems  which  the  organization  must  support. 

Stmctural  quality  describes  the  structure  or  architecture’  of  the  software  systerrL  The  software 
architecture  may  be  well-structured  and  suitable  for  quickly  converting  to  a  modem 
programming  language  or  hardware  platform.  In  this  case,  translation  can  be  an  effective 
means  for  performing  this  conversion.  Poorly  stmetured  software  is  a  candidate  for  code 
restmeturing  or  for  reverse  engineering  to  produce  a  design  representation  that  can  then  be 
restructured  [MrrR92].  Poor  structure  may  cause  autonuted  tools  difficulty  in  aiuilyzing  the 


*  Architecture  includes  the  implementation  design  of  the  software.  The  term  Design  is  used  to  define  a 
criteria  under  Development  Factors  that  refers  to  the  existence  of  a  high-level  representation  of  the  software. 
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source  code.  Time  may  be  wasted  on  analyzing  and  reverse  engineering  dead  code  that  is  of 
no  value  to  the  system  requirements.  It  may  be  advantageous  for  a  team  of  programmers  to 
examine  the  code  manually,  identifying  such  areas  in  the  code  and  perhaps  to  manually 
discard  or  modify  them.  Redocumentation  techniques  can  often  report  on  the  structural 
quality  of  source  code.  Automated  redocumentation  exists  that  generates  structure  charts^ 
which  define  the  procedures  used  to  inq)lement  the  software,  including  the  calling  hierarchy, 
naming  conventions,  and  input  and  output  of  data  between  these  modules.  This  is  useful  in 
quickly  identifying  modules  which  are  never  executed,  are  not  represented  in  an  existing  high- 
level  design,  or  utilize  global  data  [STSC92]. 

4. 1.1. 2  System  Characteristics.  System  characteristics  describe  any  commercial  or  external 
software  packages  that  integrate  with  source  code  to  form  a  complete  system.  These 
characteristics  also  include  alternate  configurations  in  which  the  system  exists  for  different 
customers  and  external  software  applications  with  which  the  software  interacts  to  meet  hig^- 
level  requirements.  The  overall  requirements  that  this  system  performs  that  may  be  outdated 
and  the  inqxwtance  of  the  system  to  the  organization  are  also  part  of  this  criteria. 


System  Chafacteristics 
Alternate  configurations 


Commercial  software  interface 


Requirement  obsolescence 


Description 

whether  or  not  there  are  alternate  configurations  of  this 
system:  if  so.  a  description  of  these  configurations  and 
scenarios  for  when  each  is  an  alternative 

number  of  commercial  software  packages  that  interface; 
and  a  description  of  that  interface 

to  what  degree  the  system  requirements  are  no  longer 
viable;  which  requirements  are  viable 


Alternate  configurations  identifies  whether  or  not  there  are  alternate  configurations  of  this 
software  system.  The  requirements  justifying  these  versions  should  be  identified  and  it  should 
be  determined  whether  die  alternate  configurations  can  be  consolidated  into  a  single  software 
system.  Restructuring  the  system  may  inqirove  modularity  for  identifying  specific  functions 
and  enable  a  system  to  incorporate  functions  previously  performed  in  other  systems.  Reverse 
engineering  permits  the  consolidation  of  these  functions  into  a  uniform  design  representation 
that  can  then  be  used  to  generate  the  new  software  system. 

Commercial  software  interface  describes  the  number  of  commercial  software  packages  that 
interface  the  software  system.  It  is  inqiortant  to  identify  all  of  these  interfaces  and  understand 
die  structure  of  each  to  insure  that  any  reimplementation  or  modification  to  the  existing 
software  does  not  alter  this  interface.  Reengineering  is  considered  for  improving  poorly 
integrated  system  components  [MITR92].  Most  modernization  efforts  integrate  commercially 


*  Structure  charts  depict  the  structure  of  the  software  as  defined  by  Edward  Yourdon  and  Larry  Constantine 
a,  Englewood  Cliffs,  NJ;  Prentice  Hall,  1979. 
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available  software  components,  including  database  management  systems  (DBMS)  and  other 
software  packages  to  meet  system  requirements.  The  key  issue  in  most  of  these  integration 
efforts  is  the  data  interchange  format.  Commercial  packages  do  not  easily  interact  with  older 
programming  languages  of  hardware  platforms,  thus  requiring  conversion  to  new  software  and 
hardware  in^lementations.  Reverse  engineering  the  software  to  a  design  representation 
provides  a  means  for  achieving  this  type  of  conversion.  The  design  can  be  restructured  to 
better  integrate  commercially  available  system  components  and  reimplemented  in  modem 
programming  languages  for  state  of  the  art  hardware. 


Requirement  obsolescence  describes  to  what  degree  the  system  requirements  are  no  longer 
viable.  Current  system  functionality  may  not  conform  to  user  ne^s.  Obsolete  requirements 
should  be  eliminated  from  the  existing  system  during  reengineering.  Source  code  which 
performs  these  requirements  should  be  extracted  from  the  software  prior  to  restracturing  if 
possible,  else  afterwards.  Reverse  engineering  to  the  design  level  may  noore  easily  identify 
the  pmtians  of  the  software  performing  these  outdated  requirements  and  can  easily  be 
renwved  fixun  the  design  prior  to  reimplementation. 


4. 1. 1.3  Environment  Characteristics.  Envirorunent  characteristics  describe  the  organization's 
primary  functions  with  respect  to  how  the  software  system  operates.  Domains  of  interest 
which  the  <wganization  supports  are  defined  within  this  information  system(s),  including 
persoimel  management,  financial,  and  procuremoit.  The  software  system  executes  on 
cortq)uter  hardware  and  possibly  interfaces  with  other  hardware  components.  The  high-level 
organizational  goals  which  this  system  supports  also  reflect  the  operational  environment.  The 
number  and  type  of  external  interfaces  and  how  the  system  is  used  are  also  part  of  the 
operational  environment. 


Environment  Characteristics  Description 


Domain  consistency 


Hardware  interface 


Organizational  goals 


Usage 


whether  or  not  the  system  exists  within  a  domain  and  the 
description  of  that  domain;  whether  or  not  the  system 
needs  to  fit  within  a  domain  and  a  description  of  that 
domain  (e.g.,  personnel,  financial) 

definition  of  the  hardware  upon  which  the  system 
depends  and  a  description  of  this  interface;  whether  or 
not  the  system  can  reside  on  more  than  one 
hardware/software  platform;  identification  and  description 
of  those  platforms  if  currently  residing  on  more  than  one 

desaibes  the  high-level  goal(s)  of  the  organization 
relative  to  this  software  system  and  the  function  this 
system  plays  in  accomplishing  this  goal(s). 

number  and  type  of  interactions  with  the  system  by 
individuals,  other  organizations,  and  external  automated 
systems 
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Domain  consistency  describes  whether  or  not  the  system  exists  within  a  domain  and  the 
description  of  that  domain.  Modifications  to  the  system  must  conform  within  the  constraints 
of  this  domain.  Often  reverse  engineering  is  performed  to  migrate  a  software  system  to  a 
domain  that  provides  consistency  across  similar  applications  in  an  organization. 
Rein^lementation  of  the  new  system  ^ould  consider  reuse  options  for  achieving  domain 
consistency  as  well  as  consolidation  of  fimctionality  across  multiple  software  systems. 

Hardware  interface  describes  the  current  hardware  platform  upon  which  the  software  system 
executes  and  a  description  of  the  dependencies  of  Ae  software  on  this  platform.  The 
hardware  debilities  often  restrict  software  implementation  options  and  these  may  change 
given  an  alternative  platform.  Antiquated  hardware  is  often  the  reason  for  modernizing  the 
software  system  [MITRE92].  Fewer  dependencies  may  ease  migration  to  a  new  hardware 
configuration,  while  strong  ties  may  inq)act  the  technical  approach  taken  to  riKxlemize  the 
software.  Reverse  engineering  is  usefiil  for  generating  a  h^ware-independent  design  of  the 
software  and  determining  implementation  dependencies  A\hich  resulted  from  that  platform. 

The  hardware-independent  design  can  then  be  implemented  for  alternate  hardware 
configurations. 

Organizational  goals  describes  the  high-level  goals  of  the  organization  relative  to  the  software 
system  and  die  function  this  system  plays  in  accomplishing  these  goals.  Room  defines  the 
high-level  goals  of  most  organizations  to  include  die  elimination  of  non-essential  products  and 
increase  the  value  of  those  remaining.  [Room92].  Reengineering  should  only  be  performed 
after  careful  analysis  of  how  the  software  systems  within  an  organization  currendy  support 
these  primary  functions.  Keyes  quotes  C.  Finkelstein^  who  said,  "Legacy  code  contains  the 
business  rules  of  an  organization  at  a  particular  time"  [Keye92,  p39].  Since  the  organization 
must  adapt  to  the  changing  environment  to  stay  competitive,  the  software  system  must  allow 
the  flexibility  to  adapt  as  well.  Software  systems  which  no  longer  support  the  organization's 
primary  functions  and  goals  should  not  be  considered  for  reengineering;  these  systems  are 
seldom  used  and  should  be  discarded.  Systems  of  minimal  to  moderate  use  that  do  not 
siqipoit  these  activities  should  be  further  examined  for  individual  component  importance. 
Relevant  components  should  be  identified,  isolated,  and  stored  for  possible  integration  into 
other  systems  of  importance  in  software  reuse.  Only  those  systems  addressing  the  current 
inimary  functions  and  future  goals  should  be  considered  for  reengineering. 

Usage  describes  the  amount  of  use  the  software  system  undergoes,  including  the  number  and 
type  of  interactions  with  the  system  by  individuals,  external  organizations  and  other 
automated  systems.  The  needs  of  these  entities  must  be  maintained  when  modemmng  the 
system.  In  many  cases  it  is  precisely  these  needs  that  are  driving  the  reengineering  effort. 
Nfod  jjiiizing  the  system  promises  to  improve  response  times  by  the  system  as  well  as  by 
maiiitainers  responding  to  change  requests  from  die  users.  Reverse  engineering  to  an 


^  Clive  Finkelstein  is  the  founder  of  Information  Engineering  Systems  Corporation  (lESC),  Alexandria,  VA. 
He  writes,  lectures,  and  espouses  methodologies  for  information  engineering,  and  has  recently  completed 
Information  Engineering:  Strategic  Systems  Development.  Addison-Wesley  Publishers,  1992. 
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automated  support  environment  helps  in^>rove  the  riKxlification  process.  Redocumentatirm 
provides  supporting  documentation  to  maintainers  making  decisimis  about  modifkaticms. 
Restructuring  the  software  may  enable  the  system  to  more  readily  accept  modificatitms 
without  n^atively  in^acting 
other  parts  of  the  system. 


4.1.2  Process  Factors.  Process  factors  describe  the  aspects  of  the  origiiud  development 
process  and  the  maintenance  prcx^s  which  have  impacted  the  current  implementation  of  the 
software  system. 

4. 1.2.1  Development  Factors.  Development  factors  define  aspects  of  the  development  process 
\^ch  have  affected  the  software  system  in^lementation.  The  development  process  for  a 
software  system  is  key  to  how  wdl  it  can  be  maintained  throu^out  its  life-cycle.  The  age  of 
the  softwue  can  indicate  the  software  engineering  practices  oi^loyed  at  the  time  of 
develqnnent  and  reflects  the  usefulness  of  die  software.  The  availability  of  original 
developors  is  helpful  for  imraveling  the  mysteries  of  design  and  implementation  decisions. 

The  use  of  documoited  standards  in  the  development  process  may  also  have  supported  the 
creation  of  a  quality  software  system. 

Develooment  Factors  Descrtotion 

Design  comprehensive  high-tevet  de^n  of  the  software  that  is 

consistent  and  complete  to  the  current  implementation 

Development  methodology  whether  or  not  a  well-defined  development  procedure 

was  used;  whether  it  is  documented  in  text  available  to 
the  pt4)iic;  whether  or  not  this  methodology  is  supported 
by  automation 

Documentation  supplemental  documents  including  reports,  tables,  users 

guides  wNch  describe  aspects  of  the  system  not 
necessarily  relating  to  the  design 

Standardization  use  of  well-documented  development  standards, 

continued  throughout  maintenance 

Design  is  a  comprehensive  high-level  representation  of  the  software  that  is  consistent  and 
corrqilete  to  the  current  inqilementatioiL  If  this  representation  exists,  it  may  be  used  or 
restructured  to  reinqilement  the  software  in  a  standard  development  process.  If  the  existing 
design  is  not  consistent  rn*  complete,  it  may  be  used  as  siqiplemental  documentation  during  a 
reverse  engineering  process  which  will  produce  a  more  comprehensive  and  current 
representation.  Reverse  engineering  is  used  to  generate  designs  for  software  systems  that  do 
not  have  an  available  design  that  is  complete  or  consistent  with  the  current  inqilementation  of 
the  software  system  that  is  useable  in  a  effective  maintenance  process.  This  may  include 
designs  that  were  not  originally  developed  using  structured  modeling  techniques  or  are  not 
siqiported  by  an  automated  process  (automation  provides  necessary  efficient  maintenance 
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support)  [McCa92].  The  design  may  serve  as  an  end  product  that  provides  system 
understanding  or  may  serve  as  a  means  for  implementing  a  new  system  with  added 
fiuictionality  or  new  programming  language.  Reverse  engineering  the  data  model  for 
informatKMi  systems  oRai  lends  insight  into  how  to  restructure  the  data  for  an  in^roved 
inqplementatitm. 

Development  methodology  identifies  v^ether  or  not  a  well-defined  development  procedure 
was  us^  in  developing  this  software.  If  a  documented  methodology  was  used,  then  it  may  be 
easier  to  understand  the  in^)act  of  this  methodology  on  the  implementation  of  the  software 
and  the  design  of  the  software,  if  it  exists.  It  is  also  important  to  note  if  automation  was  used 
in  developing  the  software  system.  If  the  previous  development  procedure  is  still  a  viable 
development  methodology,  then  consideration  should  be  given  for  utilizing  this  method  in 
regenerating  the  software  system 

Dncumentation  describes  any  reptxts,  tables,  mr  design  record  that  exists  for  the  software 
system  Documentation  is  credited  with  being  the  key  to  adequate  software  maintenance,  and 
yet  it  is  still  the  most  unqualified  segment  of  the  software  engineering  process. 

There  are  useful  suggestions  that  can  be  perftvmed  immediately  to  improve  the 
documentation  status  of  a  software  system  [Hova92].  Obsolete  documents,  such  as  those  that 
have  not  been  used  in  more  than  a  year,  should  be  discarded  since  they  are  either  outdated  or 
unusable.  Perftxm  a  documentation  audit  to  determine  what  documents  are  needed  and  set 
about  generadi^  ftiese  documents  or  making  additions  to  existing  inconq>lete  documents. 

This  can  be  pofonned  by  examining  trouble  reports  that  were  diagnosed  as  help  requests,  or 
the  user  help  requests,  if  these  are  logged.  Fiiuilly,  new  development,  as  well,  as 
reengineefing  should  establish  documentation  as  a  top  priority  in  these  processes.  A  lade  of 
adequate  documentation  is  the  most  common  reas<ni  fm:  considering  reengineering  [Ruhl91]. 
Redocumentation  techniques  produce  various  types  of  documents  to  supplement  the  software 
system  inqrlementations  (specification,  design,  source  code).  Reports  defining  the  variables, 
procedure  calls,  and  procedure  interfaces  can  be  useful  in  gaining  a  better  understanding  of 
die  software.  Documentation  siq)ports  reverse  engineering  by  providing  supplemental 
inftumation  that  is  useful  in  distinguishing  design  and  requirements  information  frmn 
inqrlonentation  idiosyncracies. 

StandarHiTarinn  describes  the  Utilization  of  standard  development  techniques  during  the 
origitud  devdqnnent  process.  These  techniques  may  be  proprietary  standards,  internal  to  the 
organization,  or  may  be  DoD  standards  (e.g.,  DoD-STD-2167  or  the  proposed  MIL-STD- 
SDD).  The  standards  used  in  the  development  of  the  existing  software  may  provide  insight 
into  why  design  and  implementation  decisions  were  made,  and  to  where  modernization  can  be 
applied  to  the  software.  No  utilization  of  documented  standards  indicates  that  the  software 
^uld  probably  be  converted  to  an  inqrlementation  that  adheres  to  current  software 
oigineermg  standards.  This  can  be  achieved  through  translation  (for  language  conversion),  or 
reverse  engineering  to  a  more  open  systems  enviromnent. 
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4. 1.2. 2  Maintenance  Factors.  Maintenance  Factors  define  asf)ects  of  the  maintenance  process 
which  have  affected  the  software  system  implementation.  A  common  reason  for 
reengineering  is  often  an  inability  to  adequately  maintain  the  existing  software  [MITRE92]. 
A  good  development  process  can  easily  be  weakened  by  poor  maintenance  practices.  Many 
systems  have  survived  years  of  unmonitored  modifications  to  the  software,  resulting  in 
unstable  implementations.  The  criteria  to  consider  concerning  maintenance  are  listed  below. 


Maintenance  Factors 
Automation 

Configuration  management 
Improvement  status 

Life  expectancy 
Modification  effort 

Modification  rate 


Description 

whether  or  not  an  automated  process  is  used  for 
modifications 

a  management  process  for  controlling  and  documenting 
modifications  and  versions  of  the  software  system 

to  what  degree  the  system  could  be  improved  to  meet 
current  known  requirements  and  a  description  of  these 
improvements;  to  what  degree  the  system  could  be 
improved  to  meet  current  known  requirements  efficiently. 

the  number  of  years  this  system  is  expected  to  remain  in 
operation 

rate  of  modification  over  number  of  modifications 
multiplied  by  the  average  number  of  maintainors  to 
compete 

number  of  modifications  per  a  given  period  of  time 
relative  to  a  desired  number 


Automation  factor  identifies  whether  or  not  an  automated  process  is  used  for  supporting  the 
existing  system  configuration.  Incorporating  automation  is  usually  a  high-level  goal  of  most 
organization  since  it  can  increase  the  efficiency  of  many  processes,  including  development 
and  maintenance  [Room92].  Automated  tools  can  assist  the  maintenance  process,  including 
language  sensitive  editors  for  performing  source  code  nnodifications  and  automated 
configuration  management  to  provide  version  control  and  document  the  changes  made  to  the 
software.  Preparation  for  maintenance  can  begin  in  the  development  process.  Computer- 
aided  software  engineering  (CASE)  tools  which  can  be  used  to  design  and  develop  software, 
should  also  be  used  to  maintain  it.  Redocumentation  is  the  most  mature  automation 
capability.  Redocumenting  the  software  using  an  automated  tool  can  provide  fast  information 
about  the  source  code  architecture.  Reverse  engineering  the  software  into  a  CASE  tool  serves 
to  automate  the  maintenance  process. 

Configuration  management  identifies  whether  or  not  a  formal  process  exists  for  controlling 
and  documenting  modifications  to  the  software  and  alternate  versions  of  the  system.  This 
process  may  document  the  information  helpful  in  identifying  problem  areas  in  the  system, 
those  which  are  modified  or  corrected  oftm.  These  functions  may  be  isolated  and 
implemented  in  a  modem  software  system. 
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Improvement  status  identifies  to  what  extent  the  system  is  operating  according  to  the  current 
system  requirements.  There  are  several  methods  for  measuring  faults  in  source  code, 
including  Gafhtey*.  If  there  are  current  defects  in  the  software  or  modifications  that  have 
been  requested  which  have  not  been  implemented,  either  due  to  modification  effort  or  cost, 
this  may  be  a  good  time  to  ccmsider  reengineeiing  options.  An  analysis  of  the  system  may 
identify  isolated  parts  of  the  software  which  ate  not  performing  adequately.  These  parts  may 
be  reverse  engineered,  modified  at  the  design  level,  and  reimplemented.  The  corrected  parts 
can  then  be  integrated  back  into  the  remaining  software.  Most  existing  source  code 
components  are  so  tightly  interweaved,  that  it  is  usually  necessary  to  reverse  engineer  the 
entire  software  system  and  generate  a  more  modular  software  system. 

This  criteria  also  identifies  to  what  degree  the  system  could  be  improved  to  meet 
current  known  requirements  efficiently.  If  the  system  has  many  modifications  that  are 
necessary  in  (xder  for  it  to  teach  an  acceptable  level  of  performance,  then  consideraticHi 
should  be  given  ftn*  vdiether  this  software  should  ccmtinue  as  a  functioning  element  in  the 
oiganizatioiL  It  should  be  clearly  understood  v^t  changes  are  necessary  and  incorporate 
those  into  a  reengineering  process.  Restracturing  can  be  applied  to  improve  the  performance 
of  the  software  without  introducing  new  functionality.  Reverse  engineering  can  be  used  to 
abstract  a  high-level  design  which  could  then  be  used  to  incorporate  new  funcdoiudity  that  is 
in:q>lemented  in  a  new  software  systeoL 

Life  expectancy  identifies  the  number  of  years  this  software  system  is  expected  to  remain  in 
operation.  The  system  may  not  be  operating  much  longer  because  the  functions  are  becoming 
outdated  or  because  the  software  system  has  been  designated  for  replacement.  If  the  software 
is  not  expected  to  be  in  use  much  longer  due  to  functional  obsolescence,  only  inq>tovements 
to  the  current  maintenance  process  should  be  considered.  If  the  software  has  been  designated 
fm:  replacemoit,  certain  reengineeiing  capabilities  are  feasible.  Only  available  resources 
should  be  applied,  including  automated  tools  which  currently  exist  in  the  organization. 
Minimal  redocumentation  and  restructuring  should  be  performed  to  provide  quick  benefits  for 
inqiroving  maintenance  and  extending  the  life  of  the  system  to  insure  it  remains  operational 
until  replacemoit  can  be  made.  Extensive  redocumentation,  restructuring,  and  reverse 
engineering  of  obsolete  systems  should  be  considered  only  if  the  option  of  replacing  the 
system  can  be  upheld  by  revitalizing  the  existing  one  through  these  efforts. 

Modification  effort  (A/J  identifies  the  rate  of  modification  (A/J  over  number  of  modifications 
(n)  multiplied  by  the  average  number  of  maintainers  (m)  to  complete  (Af,  =  A//n*m).  If  the 
existing  software  is  very  difficult  to  maintain,  this  may  be  a  sign  that  it  needs  to  be 
reengineered.  The  software  maintainers  should  be  interviewed  to  determine  if  the  difficulties 
are  due  to  a  lack  of  understanding,  complexity  of  the  software,  result  in  "rippling  effect"  that 
leads  to  more  problems. 


*  Gaffney,  John  E.,  "Estimating  the  Number  of  Faults  in  Code,"  IEEE  Transactions  on  Software 
Engineering-  vol  SE-10,  no.  4,  July  1984,  r).  459-465. 
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Software  understanding  may  be  enhanced  through  the  generation  of  supporting 
documentation.  Redocumenting  the  software  to  identify  interrelationships  between  the 
software  components  can  improve  maintenance  procedures.  This  can  be  useful  when 
modifying  software  for  predicting  effects  of  chwge  on  other  parts  of  the  software. 
Restractuiing  the  software  may  reduce  its  complexity,  and  eliminate  unnecessary  code.  Both 
of  these  techniques  may  reduce  the  chances  that  one  modification  to  the  software  may  have  a 
disastrous  effect  on  other  parts  of  the  software.  Severe  problems  may  only  be  solved  through 
reverse  engineering  and  a  complete  regeneration  of  the  software  system. 

Modification  rate  (A/,)  identifies  the  number  of  modifications  per  a  given  period  of  time 
relative  to  a  desired  number.  A  large  number  of  requests  to  correct  or  minify  the  software 
system  may  be  an  indication  that  this  system  is  not  currently  meeting  the  nee^  of  the 
intended  users,  has  hidden  defects,  or  is  struggling  to  perform  too  many  requirements.  An 
analysis  should  be  performed  to  identify  vdiat  the  system  actually  does  relative  to  what  die 
users  of  the  system  expect  it  to  do.  RedocumentatitMi  techniques  should  be  used  to  define  the 
functions  and  performance  of  the  existing  software.  Critical  functions  that  the  software 
performs  should  be  identified,  isolated  and  perhaps  reused.  Reverse  engineering  the  software 
can  also  help  provide  a  better  understanding  of  what  the  software  does,  and  the  subsequent 
design  can  be  used  to  implement  a  new  system  that  better  meets  the  needs  of  the  intended 
users.  This  new  system  ^ould  integrate  reusable  modules.  Testing  should  be  performed  on 
the  existing  software  based  on  these  requirements  to  insure  that  the  system  is  performing 
accurately.  If  the  system  is  performing  too  many  requirements,  steps  should  be  taken  to 
isolate  and  identify  the  functions  of  the  software  to  determine  wheAer  a  more  cohesive 
system  can  be  developed  which  better  fulfills  the  needs  of  the  users. 


4.2  Reengineered  Software  System  Criteria 

Reoigmeered  Software  System  Criteria  include  those  criteria  which  describe  the 
desired  products  of  reengineering  and  the  factors  which  influence  the  reengineering  process. 


4.2.1  Product  Characteristics.  The  Product  Characteristics  describe  the  desired  characteristics 
of  the  target  software,  the  new  support  environment,  and  the  new  operation  environment. 


4.2. 1.1  Tareet  Software  Characteristics.  The  characteristics  of  the  target  software  describe  the 
modifications  that  are  desired  between  the  existing  software  and  the  new  software. 


laraet-Software  Characteristics  Description 

Functional  improvement  number  and  type  of  functional  modifications  which  are 

desired  in  parallel  to  the  reengineering  of  this  system; 
test  suite  tor  verifying  these 
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Language  migiation  identification  and  description  of  the  language 

implementation  requested  for  this  system 

Performance  improvement  identification  and  description  of  the  desired  performartce 

improvements  for  this  system;  test  suite  for  validating 
these 

Technology  insertion  identification  of  specific  technology  advances  that  coukJ 

be  implemerrted  to  improve  the  software  system, 
including  new  commercial  packages 


Functional  improvement  describes  the  number  and  type  of  functional  modifications  \yduch  are 
required  fcM*  this  system.  If  the  number  of  lines  of  code  changing  is  predicted  to  be  more  than 
twdve  percent,  it  is  often  suggested  that  die  reengineering  effort  is  too  great,  and  that 
consideiatiini  should  be  given  fot  redeveloping  the  software  system  [Keye92].  The  rational 
bdiind  Keye's  percentage  is  not  clear,  however,  die  point  is  to  weigh  the  level  of  effmt  for 
the  reengineering  with  that  of  redevelr^nnent  Minor  functional  enhancement  can  usually  be 
performed  through  the  maintenance  process.  Reengineering  is  useful  when  minor  changes  are 
not  easily  made  to  the  existing  system  or  when  there  are  enou^  changes  to  warrant 
redeveloping  the  system,  but  there  are  no  available  resources  to  support  a  conqilete 
development  project 

T  jiTiyiiaye  migration  describes  the  identification  and  description  of  die  language 
inqilementation  requested  for  this  system.  There  are  several  reasons  for  reimplementing  the 
software  in  a  different  programming  language,  including  implementation  inqirovements 
offered  by  the  language  or  the  desire  to  inqilement  all  sofb^re  in  a  common  language  within 
an  organization  to  ease  maintenance.  Within  DoD,  the  standard  programming  language 
selected  is  Ada.  Most  modernization  efforts  within  DoD  are  required  to  use  Ada. 
Reengineering  the  existing  software  to  Ada  is  one  way  to  adhere  to  this  mandate.  If  the 
current  language  inqilementation  is  similar  to  Ada,  translation  can  be  performed  to  the  new 
in^lanentation  and  if  necessary  manual  code  generation  for  the  software  which  does  not 
easily  convert  Reverse  engineering  to  a  high-level  design  and  then  regenerating  the  software 
in  Ada  is  another  optitnt  Often  the  existing  system  implementation  is  used  as  die  baseline,  a 
design,  or  siqiporting  documentation  vdiich  is  referenced  when  generating  a  new  software 
system  in  the  target  language  manually.  This  may  prove  to  be  the  most  time-consuming 
effort. 


Performance  improvement  describes  the  identification  and  description  of  the  desired 
performance  inqirovements  for  this  system.  These  improvements  may  be  achievable  in  the 
existing  software  implementation,  and  this  should  be  considered.  Aldiough,  more  oftoi  these 
performance  requirements  require  improved  hardware  or  new  software  implementation. 
Improving  the  performance  of  the  software  may  be  an  opportunity  to  reengineer  to  a  new 
system  implementation.  Translation  to  a  new  software  language  for  execution  on  a  new 
hardware  platform  is  one  of  the  fastest  migration  techniques,  however  the  translated  software 
may  not  utilize  the  capabilities  of  the  target  language  or  the  new  hardware.  Reverse 
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engineering  to  a  high-level  design  which  can  then  be  targeted  for  a  new  hardware  suite  is  one 
way  to  achieve  these  performance  improvements. 

Technology  insertion  is  the  identification  of  specific  technological  advances  that  could 
in^rove  the  implementation  of  the  software.  This  criteria  does  not  include  automated  supp(»t 
for  the  developmoit  or  maintenance  of  software,  which  is  defined  in  New  Support 
Characteristics.  The  awareness  of  new  technology  that  may  support  the  existing  fimctionality 
of  the  current  software  system  or  new  requirements  that  are  to  be  incorporated  into  the 
existing  system,  may  be  performed  through  reengineering  [M1TRE92].  Reusable  comptments 
may  be  incorporated  into  the  existing  system  to  replace  outdated  components  and  improve  the 
performance  of  the  software.  Often  improved  data  management  facilities  may  be  incorporated 
into  an  information  system  which  previously  performed  its  data  management  in  an  ad-hoc  <»* 
hard-coded  manner.  Reverse  engineering  the  data  models  fix>m  the  software  and  incorporating 
a  commercial  database  may  iiiq)rove  data  management  New  programming  languages  may  be 
used  to  implement  a  softtn^uc  system  that  contains  in^roved  library  routines,  fimctions  and 
data  structures  that  better  support  the  system  requirements.  Reverse  engineering  can  salvage 
an  existing  software  design,  which  can  then  be  restructured  and  reimplemented  into  a  nx>re 
modem  software  system  that  utilkes  advanced  software  engineering  technology. 

4.2.1  New  Support  Characteristics.  New  support  characteristics  define  the  qualities  desired 
in  a  new  maintenance  process.  The  transition  to  a  new  siq>port  enviroiunent  is  often  the 
reason  for  considering  reengineering.  An  organizational  decision  has  been  made  to  maintain 
software  systems  using  automation,  necessitating  the  move  of  existing  systems  to  the  toofs 
environment.  This  decision  may  be  useful  in  providing  more  efficient  support  for  software, 
but  the  overhead  of  altering  the  software  to  enable  this  support  may  out-weigh  the  move. 
Issues  concerning  this  technology  insertion  should  be  considered  carefully. 


New  Support  Characteristics 
Adaptability 

Automation  insertion 
Domain  consistency 
Maintenance  improvement 


Description 

to  what  extent  the  new  support  environment  will  enable 
the  software  system  to  ad^t  to  a  changing  environment. 
i.e..  enhancements,  alternate  software/  hardware 
implementations,  integration  of  new  components 

desire  to  maintain  the  software  system  using  automated 
techniques 

to  what  extent  the  new  support  environment  supports 
other  systems  in  the  same  domain 

identification  and  description  of  specific  improvements  to 
the  overall  maintenance  process;  to  what  degree  the 
current  maintenance  pra^ices  are  no  longer  useful; 
description  of  the  problems 
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Adaptability  describes  to  what  extent  the  new  support  environment  will  enable  the  software 
system  to  adapt  to  a  changing  environment,  i.e.,  enhancements,  alternate  software/hardware 
implementations,  integration  of  new  components.  These  characteristics  will  prepare  the 
software  system  for  future  migrations.  Reengineering  is  often  used  to  modernize  the  software 
to  a  implementation  that  is  better  suited  for  hiture  migrations  [MrTR£92].  Restmctuiing  the 
data  model  and  software  architecture  may  better  prepare  the  software  for  future  modifications. 
Reverse  engineering  the  software  into  a  CASE  tool  may  facilitate  the  generation  of 
impleiiKntations  in  alternative  languages.  Eliminating  hardware  dependencies  when  using  the 
recovered  design  in  a  new  implementation  may  make  the  software  more  portable  for  future 
migrations  to  new  or  alternative  hardware  platforms. 

Automation  insertion  describes  the  automated  techniques  that  are  needed  to  support  the  new 
stq>port  environment  This  criteria  does  not  include  implementation  techniques  supplied  by 
te^ological  advances  in  software  development,  which  was  addressed  in  Target  Software 
Oiaracterisdcs.  The  desire  to  automate  the  maintenance  environment  is  often  the  reason  for 
modernizing  a  software  system  [MrrRE92].  CASE  tools  which  are  used  to  develop  software 
systems  are  tiseful  throu^out  the  life  of  the  software  by  supporting  modifications  to  the 
source  code  while  updating  designs  and  documentation. 

Steps  can  be  taken  to  integrate  CASE  into  the  existing  software  engineering 
enviixHiment  within  an  organization  [CIM92].  This  is  most  often  successful  in  more  modem 
softvrare  systems  and  mature  organizations.  Many  programming  languages  and  older 
hardware  platforms  do  not  support  modem  CASE  tools,  thus  forcing  the  modernization  of  the 
software  system  itself.  Reverse  engineering  provides  a  means  for  extracting  information  and 
populating  CASE  repositories  with  data  that  can  be  used  to  support  the  current 
implementation.  CASE  often  includes  code  generation  support  for  reimplementing  the 
software  into  a  more  modem  programming  language. 

Domain  consistency  describes  to  what  extent  the  new  support  environment  supports  other 
systems  in  the  same  domain.  Systems  that  reside  in  a  identifiable  domain  should  be 
crmsidered  for  reengineeting  for  achieving  commonality  through  software  reuse  and 
consolidation.  Redocumentation  techniques  can  be  usai  to  identify  commonality  between 
software  systems.  Software  system  should  be  consolidated  where  possible.  Reverse 
engineering  systems  within  a  single  domain  can  enable  the  generation  of  a  consolidated 
system  from  separate  software  programs  implemented  in  varying  languages  and  executing  on 
(Offering  hardware  platforms.  Reuse  modules  should  be  used  to  implement  common 
functionality  when  possible. 

Maintainability  describes  to  wdiat  extent  the  new  support  environment  provides  improvements 
to  the  overall  maintenance  process.  This  identifies  specific  technological  advances  that  are  a 
part  of  the  new  support  environment  that  improve  the  process  of  supporting  the  system 
software  and  a  description  of  how  this  is  accomplished.  The  integration  of  CASE  tools 
promises  to  enable  faster  modifications  to  the  software  and  automatic  updates  to  supporting 
documentation.  Reverse  engineering  is  used  to  produce  a  high-level  design  representation  that 
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can  be  stored  and  automatically  supported  within  a  CASE  tool.  The  ability  to  make  changes 
and  generate  updates  to  this  representation  and  subsequently  the  implementation,  should 
improve  response  time  to  change  requests. 

4.2. 1.3  New  Environment  Characteristics.  New  &ivironment  Characteristics  describe  the  new 
operational  environment  to  which  the  existing  system  must  migrate.  New  operational 
environment  is  the  most  common  cause  for  considering  reengineering.  The  new  enviroiunent 
may  include  the  requirement  to  achieve  domain  consistency,  migration  to  new  hardware 
platforms,  as  well  as  new  system  requirements. 


New  Environment  Characteristics  Description 

Domain  integration  identification  and  description  of  the  new  target 

domsun 


New  hardware  platforms 


New  usage 


New  organizational  goals 


number  and  type  of  hardware  interfaces  wNch  are 
to  be  integrated  to  this  system;  identification  and 
description  of  alternative  or  new  hardware 
platforms 

new  people,  organizations,  or  automated  systems 
that  must  now  interface  with  this  software  system 

new  organizational  goal  that  must  be  addressed  by 
this  software  system  and  how 


Domain  integration  is  the  identification  and  description  of  the  new  target  domain.  The 
domain  may  be  the  programming  language,  hardware  platform,  or  functional.  Domains  from 
which  the  current  system  is  far  removed  may  be  more  difficult  to  reach  through  reengineering 
and  may  require  a  completed  redevelopment.  A  well-structured  and  modular  software  system 
may  incorporate  replacement  parts  that  are  reuse  software  modules  that  immediately  migrate 
the  existing  system  to  a  desired  domain. 


New  hardware  platforms  is  the  identification  and  description  of  alternative  or  new  hardware 
platforms.  An  understanding  of  the  new  hardware  platform  and  the  current  software  interface 
is  crucial  to  the  success  of  the  system  migration.  Hiis  describes  the  number  and  type  of 
hardware  interfaces  which  are  to  be  integrated  to  this  system.  The  new  hardware  platform 
often  drives  the  modification  of  the  software  to  a  new  or  alternate  version.  It  may  be 
necessary  to  restructure  or  update  the  version  of  the  current  implementation  language  to 
execute  the  software  on  the  new  hardware.  Restmeturing  may  be  necessaiy,  and  replacement 
of  new  library  modules  to  accomplish  the  same  functionality  of  the  existing  software.  This  is 
also  a  time  to  consider  an  alternate  implementation  of  the  software  in  another  programming 
language  that  is  more  compatible  with  the  hardware  and  operating  system.  Reverse 
engineering  and  regeneration  of  the  software  may  be  useful  in  generating  a  new  software 
system  for  the  new  hardware. 
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New  usage  describes  new  people,  organizations,  or  automated  systems  that  must  now  interface 
with  this  software  system.  These  new  interfaces  may  require  ftmctional  improvement, 
portability  to  new  hardware  platforms,  new  report  generation  format,  and  the  ability  to  reply 
to  increased  change  requests.  Reengineering  is  being  considered  for  several  software  systems 
within  DoD  that  have  been  selected  for  use  in  multiple  agencies  to  eliminate  redundancy,  but 
will  be  maintained  at  one  central  location  [CIM92].  Supporting  organizations  faced  with  an 
inability  to  adequately  address  current  maintenance  issues  are  now  considering  reengineering 
the  software  system  to  an  automated  envirormient  which  will  in^rove  maintenance  process. 

New  organizational  goals  describes  any  new  organizational  goal(s)  that  must  be  addressed  by 
this  software  system.  Room  presented  high-level  goals  of  an  organization  which  eliminate 
non-essential  products  and  processes,  increase  the  value  of  those  remaining;  and  increase  the 
efficiency  of  those  processes  through  streamlining,  simplification  and/or  automation 
[Room92].  The  organization  may  consider  the  candidate  software  system  as  non-essential  and 
in  this  case  the  best  option  is  to  elimiiute  this  software  system.  More  likely,  this  software 
offers  some  value  and  should  be  examined  for  potential  consolidation  with  other  similar 
systems  for  consolidation  purposes  that  will  streamline  and  simplify  maintenance. 

Automation  may  also  be  incorporated  as  discussed  in  paragraph  S.2.1.2  New  Support 
Characteristics  and  S.2.2.2  Methodology  Factors  criteria  below. 


42.2  Process  Factors.  The  process  for  performing  reengineering  is  dependent  on  the  high- 
level  goals  of  the  organization,  reengineering  methodology,  and  the  available  resources. 

4.2.2. 1  Organization  Factors.  Organizational  support  for  reengineering  is  in:q>erative  to  the 
success  of  the  effort.  Establish  the  context  for  reengineering  by  considering  the  corjwrate 
goals  of  the  organization  and  how  reengineering  could  be  applied  to  achieve  this  mission 
[Ruhl91,  pl5].  Reengineering  promises  to  provide  a  potentially  large  payoff  for  little  risk. 
However,  the  fulfUlment  of  this  promise  is  often  very  application  dependent.  A  large  portion 
of  the  billions  of  dollars  spent  over  the  past  decade  on  information  technology  was  invested  in 
the  support  and  upgrade  of  information  systems,  however,  there  have  been  no  notable 
improvements  in  information  management  [Sass91,  pl7]. 

The  time  and  expense  of  reengineering  is  often  not  understood  by  management, 
resulting  in  a  loss  of  interest  and  withdrawal  of  support.  Although  estimates  of  five  years 
before  benefits  from  reengineering  emerge  are  not  uncommon,  management  often  wants  to  see 
results  in  one  year  [Cumm92].  Benefits  from  reengineering  have  been  defined  according  to 
improvements  in  the  number  of  software  defects,  time,  and  costs  during  the  life  of  the 
software  [Wild91].  These  benefits  are  often  seen  in  as  early  as  one  to  two  years.  Realistic 
estimates  for  resources  on  individual  applications  should  be  established  initially  and 
management  support  secured  for  reengineering  success.  Resulting  benefits  from  reengineering 
should  be  measured  in  terms  of  quality  enhancement  as  well  as  cost  impact  [Vowl91].  The 
motivations  and  goal  of  the  reengineering  effort  should  be  determined  up  front  and  then  a 
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plan  for  achieving  success  developed  that  outlines  steps  to  take  and  markers  for  calculating 
success  along  the  way  [Ruhl91,  pl6]. 


Organization  Factors  Description 

Budget  constraints  budget  limitations  and  predicted  allocation  of  this  amount 

to  various  resources  a^  phases  of  the  intended 
reengineering  activity(s) 

Effort  estimations  projected  estimations  regarding  manpower  and  time  for 

performing  the  reengineering  activity(s) 

Management  commitment  definition  of  management  expectations  and  limitations; 

schedule  for  identification  of  management  objectives  and 
proof  of  progress  throughout  the  reengineering  activity(s) 

Schedule  estatHish  management  approved  schedule  for  performing 

the  reengineering  activity(s).  including  alternative  plans 
based  on  trade-offs  measured  throughout  the  activity 


Budget  constraints  identifies  budget  limitations  to  performing  the  desired  nKxlifications  to  the 
software.  Reengineering  is  often  considered  an  inexpensive  process.  In  fact,  reengineering 
can  be  quite  expensive,  particularly  during  design  recovery.  Design  recovery  may  seem  time- 
consuming  and  costly  initially,  but  can  greatly  impact  the  success  of  the  reengineering. 

Budget  must  also  account  for  the  training  of  reengineering  methods  and  tools.  The  cost  of 
continuing  in  the  current  mode  must  be  weighed  against  the  estimated  costs  of  reengineering 
to  determine  if  the  process  is  worth  the  effort  Given  that  a  conq)leted  redevelopment  is  not 
an  affordable  option  in  modernizing  the  software  system,  there  are  several  options  within 
reengineering  that  may  improve  the  current  status  of  the  system.  Restructuring  die  source 
code  is  one  of  the  least  expensive  means  for  improving  the  source  code.  Restmcturing  fta*  a 
minimum  cost  can  be  performed  to  eliminate  "dead  code"  and  gotos.  More  advanced 
restructuring  reconstructs  the  data  model  or  control  flow  of  the  software.  Redocumentation 
can  also  be  performed  to  varying  degrees  of  effort,  including  generation  of  reports  defining 
variables  and  data  structures  or  generating  a  structure  chart  showing  the  software  architecture. 
These  documents  provide  supporting  information  that  may  be  useful  during  maintenance. 
Most  expensive  effort  is  reverse  engineering  for  ftill  design  recovery.  If  the  budget  permits, 
this  is  one  of  the  most  comprehensive  processes  within  reengineering  providing  a  design 
which  can  be  used  to  reimplement  the  software. 

Effort  estimations  identifies  projected  estimations  regarding  manpower  and  time  for 
performing  the  reengineering  activity(s).  Although  fewer  people  are  likely  to  be  needed  to 
perform  reengineering,  the  expertise  of  these  individuals  becomes  more  important. 

Management  commitment  identifies  definition  of  management  expectations  and  limitations; 
schedule  for  identification  of  management  objectives  and  proof  of  progress  throughout  the 
reengineering  activity(s). 
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Schedule  identifies  the  amount  of  time  available  for  performing  the  nKxiemizauon  of  the 
software  system.  Reengineering  can  often  be  accon^lished  in  less  time  than  a  complete 
redevelopment  effort  There  are  several  reengineering  capabilities  which  can  be  performed  to 
varying  degrees  within  respective  time  frames  that  may  suit  a  hard  deadline  schedule.  Many 
capabilities  are  supported  by  automation  which  also  in^roves  time. 

42.2.2  Methodology  Factors.  Methodologies  are  proposed  for  many  reengineering  activities. 
The  apprq»iateness  of  a  methodology  is  based  on  the  needs  of  the  organization, 
characteristics  of  the  application,  funding,  and  personnel  capabilities.  The  frictors  below 
should  be  considered  prior  to  selecting  an  appropriate  methodology. 


Methodology  Factors  Description 

Automation  support  automated  support  for  the  methodology  selected  to 

perform  the  reengineering 

Forward  engineering  support  to  what  extent  the  reengineering  tools  support  the 

forward  engineering  processes;  identification  and 
description  of  the  interfaces  to  these  processes 

Methodology  selection  identify  and  select  a  well-defined  methodology;  insure 

training  is  available  and  that  the  methodology  meets  the 
goals  of  tfie  organization;  insure  that  the  methodology  is 
usa^  across  domains  and  in  support  throughout  the 
maintenance  process 

Reuse  commitment  investigate  reuse  options  whenever  possible 


Automated  support  identifies  the  automated  tools  which  support  the  reengineering 
methodology.  There  are  several  tools  available  which  support  various  reengineering  activities 
[STSC92].  It  is  inqtortant  to  be  realistic  in  what  these  tools  provide.  Investigate  their 
capabilities  and  be  prepared  to  address  inefficiencies  through  adequate  persoimel  who  are 
knowledgeable  of  these  tools  and  can  perform  processes  when  the  tools  do  not.  Considering 
the  focus  of  most  CASE  tools  for  a  particdlar  conq>uting  environment,  one  set  of  CASE  tools 
shotild  not  be  depended  on  for  uniform  applicability  to  all  needs  across  an  organization 
[Ruhl91,  p21].  b  addition,  since  several  tools  may  be  used  during  reengineering,  it  is 
impcntant  to  consider  not  only  the  impact  of  these  tools  on  the  existing  software  engineering 
envirorunent  in  the  organization,  but  whether  or  not  there  is  data  interchange  capability. 

Good  business  sense  should  be  applied  when  considering  the  purchase  of  expensive  tools. 

Forward  engineering  support  identifies  to  what  extent  the  reengineering  tools  support  the 
forward  engineering  processes;  identification  and  description  of  the  interfaces  to  tiiese 
processes. 
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Methodology  selected  identifies  a  well-defined  methodology;  insures  training  is  available  and 
that  the  methodology  meets  the  goals  of  the  organization.  A  methodology  should  be  chosen 
that  is  con^atible  to  the  requirements  of  the  organization  and  are  supported  by  automation 
where  possible  [Ruhl91,  p21].  It  is  cost-effective  if  this  methodology  is  usable  across 
domains  and  transitions  the  system  to  a  better  maintenance  process. 

Reuse  commitment  identifies  that  there  is  a  commitment  to  investigate  reuse  options  whenever 
possible.  This  is  primarily  a  concern  in  forward  engineering  where  reuse  components  should 
be  utilized  whenever  possible  to  supply  required  system  functionality. 

4.2.2.3  Resource  Factors.  Resources  for  performing  reengineering  are  composed  of  automated 
support,  including  hardware  platforms  and  tools,  and  personnel.  Reduced  resources  due  to 
biidget  cuts  are  often  the  reason  behind  considering  reengineering  as  opposed  to  standard 
development  Often  the  cost  of  reengineering  is  assumed  to  be  very  inexpensive  and  when  it 
is  not,  the  process  is  often  not  conq)leted  or  considered  a  failure.  Reengineering  should 
ultimately  be  less  expensive  than  redevelopment  or  estimates  of  continued  maintenance 
practices,  but  realistic  estimates  with  regards  to  resources  are  needed  for  successful 
reengineeting. 

4.22.3.1  Automation  Factors.  Automation  can  be  essential  to  ensuring  the  efficient  effective 
renewal  of  software  systems.  Adequate  storage  capacity  and  processor  speed  in  equipment 
stq)porting  the  reengineering  tools  are  essential  to  facilitate  the  reengineering  process  [Ruhl91, 
p21].  The  environment  suggested  to  adequately  support  the  reengineering  of  COBOL-based 
programs  utilizes  both  personal  conq)uters  and  a  mainframe  [Dyso92]. 

Using  equipment  and  tools  that  conform  to  applicable  standards  (e.g.,  POSIX)  will 
assist  in  eliminating  inconq)atibility  problems  and  will  support  future  migrations  [Ruhl91, 
pl6].  The  primary  factors  that  are  considered  in  automated  support  are  listed  below. 

Automation  Factors  Description 

Capability  limitations  limitations  on  use  of  tool,  i.e.,  maximum  number  of  users, 

limitations  on  methodology  support 

Platform  support  insure  that  hardware/operating  systems  and  integration  to 

existing  or  selected  reengineering  platform  environment; 
identification  of  platforms  supporting  tools  and  the 
limitations  of  this  support 

Target  hardware  support  relationship  of  tool  to  hardware  platform  of  reengineered 

product  (does  the  target  hardware  itself  support  the  tool, 
does  the  tool  support  the  development  of  software  for  the 
target  hardware) 

Tool  availability  does  the  tool  currently  exist  in  the  organization,  is  the 

organization  capable  of  acquiring  this  tool,  understanding 
the  cost  and  time  for  procurement 
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Capability  limitations  identifies  the  limitations  of  available  tools.  The  limitations  of  the 
methods  and  tools  must  be  understood  up-front  in  order  to  accommodate  for  automation 
inefficiencies  by  qualified  personnel. 

Platform  support  identifies  the  hardware/operating  systems  and  integration  to  existing  or 
selected  reengineering  platform  environment;  the  platforms  supporting  tools  and  the 
limitations  of  this  support 

Target  hardware  support  idoitifies  the  relationship  of  tool  to  hardware  platform  of 
reengineered  product  (  does  the  target  hardware  itself  support  the  tool,  does  the  tool  support 
the  development  of  software  for  the  target  hardware). 

Tool  availability  identifies  whether  the  tool  currently  exists  in  the  organization,  is  the 
<»ganization  ciq)able  of  acquiring  this  tool,  understanding  the  cost  and  time  for  procurotMnt 

4.2.23.2  Personnel  Factors.  Key  to  the  success  of  reengineering  is  the  availability  of  posons 
knotxdedge^le  in  both  die  existing  system,  target  system,  and  the  reengineering  process.  It  is 
critical  durt  die  existing  system  experts  be  involved  throughout  the  reengineering  process  fix' 
accomplidimg  omrect  design  recovery  [Ruhl9l,  p23].  There  must  be  commilment  from  diese 
experienced  perstxmel  to  assist  throughout  the  reengineering  effort. 

As  with  any  tedinology,  true  productivity  improvements  can  only  be  realized  through 
a  balance  of  both  enhanced  technology  and  appropriate  staffing  of  individuals  with  the 
specialized  knowledge  to  use  this  teclmology  (Sass91,  p20].  Reengineering  requires  a  hi^y 
trained  staff  that  has  experience  in  the  automated  tools  and  the  specific  programming 
languages  to  be  used  in  the  reengineering  effort  [Ruhl91,  p22].  The  inefficiencies  of  available 
tools  can  often  be  conqiensated  by  experienced  personnel.  The  Criteria  listed  below  addresses 
the  availability  of  experienced  persormel  who  take  part  in  the  reengineering  effort. 


Personnel  Factors 


Description 


Existing  system  expertise 


Target  system  expertise 


Reengineering  expertise 


does  the  personnel  exist  with  the  expertise  on  the 
existing  system  and  are  they  committed  to  the 
reengineering  effort 

does  the  personnel  exist  with  the  expertise  on  the 
desired  target  system  and  are  they  committed  to  the 
reengineering  effort 

does  the  personnel  exist  with  the  expertise  on  the 
methodology  and  automated  tools  for  performing  the 
reengineering  activity(s)  and  are  they  committed  to  the 
reengineering  effort 


Existing  system  expertise  identifies  the  personnel  with  the  expertise  on  the  existing  system. 
During  reverse  engineering  and  redociunentation,  diese  experts  should  verify  that  die 
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recovered  design  and  support  documentation  accurately  portray  the  software  system.  They 
should  also  be  consulted  to  clarify  complex  or  confusing  aspects  of  the  software  system 
throughout  the  reengineering  process.  During  restmcturing  these  individuals  should  be  used 
to  voify  that  this  process  is  not  altering  the  ftmctionality  of  the  software  system  (during 
restructuring,  existing  and  target  system  expertise  are  usually  the  same  individuals  since  only 
the  performance  aspects  of  the  system  are  altered  and  functionality  remains  the  same). 

Target  system  expertise  identifies  personnel  who  possess  the  expertise  on  the  desired  target 
systenL  These  individuals  should  verify  new  requirements  for  achieving  the  target  system  and 
should  be  consulted  to  clarify  any  confusing  aspect  of  the  proposed  target  system.  During 
forward  engineering  these  individuals  should  be  consulted  to  insure  the  new  system  meets  all 
requirements,  including  functional  and  performance.  During  restructuring,  these  individuals 
insure  that  performance  has  been  improved. 

Reengineering  expertise  whether  the  personnel  exist  with  the  expertise  on  the  methodologies 
and  automated  tools  for  performing  the  reengineering  activity(s).  These  individuals  should 
work  with  the  appropriate  experts  to  match  the  technical  approach  for  reengineering  with  the 
characteristics  of  the  software  system  and  the  desired  target  system.  If  these  experts  are  not 
available,  the  reengineering  strategy  must  supply  appropriate  training  for  the  methods  and 
tools  associated  with  the  reengineering  strategy. 
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5.  APPLICATION  AREAS  FOR  SELECTION  CRITERIA 


A  selection  criteria  can  be  used  \riien  (1)  selecting  a  system  frixn  a  set  of  functionally 
homogeneous  systems  and  (2)  selecting  a  system  from  a  set  of  heterogeneous  systems. 


S.l  Htmiogeneous  ^plication 

Hmnogeneous  systems  are  identified  by  their  similarities  in  functimiality  throu^ 
domain  analysis.  Exan^les  of  these  domains  include  Personnel,  Finance,  and  Payroll.  The 
selection  amcmg  homogeneous  ^sterns  may  support  consolidation  efforts  or  elimination  of 
multiple  cmifigurations.  The  criteria  \riiich  are  important  in  this  selection  include,  but  are  not 
limited  to  the  following: 

-  ptMtabiUty  of  system  to  alternate  hardware  platfonns 

-  existence  of  alternate  ccmfiguraticHis  for  this  system 

-  ability  of  system  to  meet  domain  requirements 

-  how  well  system  perfrMms 

-  potential  new  users  of  system 


5.2  Heterogeneous  Application 

A  single  mganizadon  may  be  re^xmsible  Rm*  many  systems  that  are  functionally  very 
different  (heterogeneous).  This  oiganization  may  have  decreasing  resources  to  adequately 
siq>port  these  systems,  including  budgets,  personnel,  and  computer  resources.  Selecting  a 
system  for  reengineering  among  heterogeneous  systems  is  often  dependent  on  some  of  the 
following  criteria: 

-  Systems  ability  to  meet  current  oiganizational  goals 

-  Amount  of  use  this  system  experiences 

-  Life  expectancy  of  this  system  (from  a  functional  view) 

-  Effmt  to  modify  system 

-  Number  of  modifications  system  has  experienced 

•  Impact  on  oiganization's  nuuntenance  costs 
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5.3  'Results  of  Effort  to  Define  Selection  Criteria  Method 


The  results  of  CIM/XE*s  effort  to  identify  a  selectirm  criteria  provided  insight  into  tiK 
way  systons  are  currently  chosen  as  candidates  for  reengineering.  Two  important  ccmclusions 
include: 

(1)  the  current  process  for  identifying  information  systems  as  candidates  for  software 
reengineering  is  tool-dependent  aiul  ad-hoc;  and 

(2)  data  from  reengineering  efforts  is  needed  to  validate  a  selection  criteria  for 
identifying  information  systems  as  candidates  ftn*  software  reengineering. 


The  current  process  for  identifying  autrMnated  information  systems  for  software 
reengineeting  is  constrained  by  the  capabilities  of  available  reengineering  tools.  The  criteria 
currently  used  to  select  information  systems  insures  that  available  reengineering  tools  will 
woric  effectively  on  these  information  systems.  Many  information  systems  in  DoD,  however, 
typically  have  very  different  characteristics  than  those  often  selected  for  reengineeting  pilot 
projects.  Table  1  depicts  a  comparison  of  these  characteristics. 


Characteristics  of  Systems  in 
Reangbieering  Pilot  Projects 

Characteristics  of  Typical  Information 
Systema  Within  DoD 

small  in  size 

Cobol-based 

rv)  external  software  interfaces 
weii^fined  functionality 
no  additional  functionality  is  required 
no  interface  with  operating  system 

very  large  (100.000^) 

may  include  assembly  or  proprietary  languages 
interfaces  with  external  software 
unknown  hmctionality/lacks  documentation 
additional  functionaTity  is  needed 
calls  to  operating  system  routines 

These  characteristics  indicate  that  software  reengineeting  is  limited  by  the  capabilities 
of  autmnated  tools.  The  technology  is  still  immature  and  not  well-defined  .  The  proof  that 
current  software  reengineering  technology  is  capable  of  fully  supporting  large-scale 
conversion  efforts  is  not  shown. 

Project  data  from  reengineering  efforts  should  help  define  a  selection  criteria  for 
identifying  information  systems  that  benefit  from  reengineering.  Currently,  there  is  not 
enough  data  or  the  type  of  data  to  support  a  formal  selection  criteria  for  selecting  information 
systems  for  software  reengineering.  As  a  result,  the  CIM/XE  woric  succeeded  in  identifying 
the  type  of  data  which  appears  to  impact  the  software  reengineering  process.  This  data  forms 
a  proposed  selection  critoia.  We  are  identifying  proposed  reengineering  efforts  that  could  be 
used  to  collect  the  data  needed  to  validate  and  evolve  the  proposed  selection  criteria. 
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6.  CONCLUSION 


Ultimately,  the  process  of  reengineering  must  support  the  high-level  goals  of  an 
oiganization,  including  (1)  eliniinati<m  of  non-essential  products  and  processes,  (2)  increase 
the  value  of  tiiose  remaining;  and  (3)  increase  the  efficiency  of  those  processes  through 
streamlining,  simplification  and/or  automaticm  [Ro(xn92].  Two  broad  concepts  so^^e  as  the 
guide  f<M'  reengineering  technology  development,  including  tiie  prevention  of  unnecessary 
diq)licati<m  by  joint  use  of  personnel,  information  systems,  facilities,  and  services  across  DoD 
and  the  ccmftxmance  to  new  regulations,  policies,  standards,  and  guidelines  for  software 
acquisiti<m  and  support.  The  Selection  Criteria  provides  insight  into  which  information 
systems  might  benefit  from  reengineering  technology  and  how. 

The  Software  Reengineering  Critoia  was  developed  using  data  gathered  from 
oooqtleted  reengineering  projects.  To  date  there  is  little  documented  experience  estimating 
the  effort  involved  in  reengineeiing.  Future  plans  are  to  gather  data  from  reengineering 
projects  to  validate  the  Criteria  as  a  means  for  identifying  software  reengineeiing  candidates. 
The  Criteria  will  decrease  in  number,  while  the  understanding  of  its  iiiq>act  cm  software 
engineoing  becomes  more  concrete.  The  applicaticm  of  tiie  Criteria  will  provide  infcmnation 
useful  in  defining  metrics  and  support  for  cc»t/benefit  analysis  for  software  reengineering.  As 
experience  buQds,  so  will  the  understanding  of  how  reengineering  should  be  performed.  This 
doomient  serves  as  the  basis  for  sudi  guidance  and  provides  information  that  will  benefit 
cxganizations  considering  reengineeiing  technology. 
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APPENDIX  A 

GLOSSARY  OF  TERMS 


A-1 


GLOSSARY 


Forward  Engineering.  Within  the  context  of  reengineering,  forward  engineering  is  the 
software  engineering  activities  that  consume  the  products  of  reengineering  activities  (primarily 
reverse  engineering),  reuse,  and  new  requirements  to  produce  a  target  system. 

Redocumentation.  The  creation  or  revision  of  a  semantically  equivalent  representation  within 
the  same  relative  abstraction  level. 

Reenyineering.  The  examination  and  alteration  of  an  information  system  to  reconstitute  it  in 
a  new  form.  The  process  enconq)asses  a  combination  of  other  processes  such  as  reverse 
engineering,  restructuring,  forward  engineering,  redocumentation,  and  translation. 

Restmcturing.  The  transformation  from  one  representation  form  to  another  at  the  same 
relative  abstraction  level,  while  preserving  the  information  system's  external  behavior 
(functionality  and  semantics). 

Reverse  Engineering.  The  process  of  examining  an  information  system  by  analyzing  its 
documentati<m,  application  software,  and  data  structures  within  the  enviroiunent  in  which  the 
information  system  operates. 

software,  within  the  text  of  this  document  refers  to  the  custom  programs  implementing  a 
given  information  system. 

Software  Reuse.  The  process  by  which  existing  software  work  products  (which  may  include 
not  only  source  code,  but  also  products  such  as  documentation,  designs,  test  data,  tools,  and 
specifications)  are  carried  over  and  used  in  another  new  development  efforts,  preferably  with 
minimal  modification. 

software  system,  within  the  text  of  this  document  refers  to  the  software,  as  well  as  any 
database  or  other  Commercial  (COTS)  package  with  which  this  software  interfaces  to  perform 
the  reqtiirements  of  the  information  system,  independent  of  the  hardware  platform  on  which 
these  (xmqmnents  execute. 

Translation.  Transformation  of  source  code  from  one  language  to  another  or  from  one  version 
of  a  language  to  another  version  of  the  same  language. 
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Existing  software  reengineering  guidance  sources  are  the  Software  Technol(^y  Support 
Center  [Sitt92],  the  Joint  Logistics  Commanders  Santa  Barbara  I  Workshop  [JLC92],  and  ^e 
National  Institute  of  Standards  and  Technology  [Ruhl91]. 


STSC's  Reengineering  Candidate  Selection  Process 

The  STSC's  Reengineering  Candidate  Selection  Process  is  based  on  a  set  of  weighted 
questi<ms  [Sitt92b,  p24]  that  are  dependent  on  three  variables:  complexity,  importance,  and 
Icmgevity.  Complexity  and  inq)ortance  of  the  software  system  are  calculated  in  terms  of  low, 
medium,  and  hi^.  The  longevity  of  the  system  is  estimated  in  terms  of  short  (less  than  six 
months),  medium  (greater  than  six  months  and  less  than  3  years),  or  long  (greater  than  3 
years).  The  following  section  summarizes  the  STSC  process. 

Regardless  of  the  complexity  and  importance,  if  the  remaining  life  expectancy  is  less 
than  6  months,  then  the  system  should  not  be  reengineered.  If  the  complexity  and  importance 
are  low  and  the  system's  life  expectancy  is  less  than  3  years,  then  the  system  is  also  not 
suitable  for  reengineering.  The  remaining  combinations  of  these  three  variables  suggests 
performing  activities  associated  with  reengineering  that  extend  from  simple  reformatting  to  a 
more  conq>lex  restructuring  of  the  software  architecture,  possibly  including  redocumentation, 
to  reverse  engineering  followed  by  forward  engineering,  and  finally  a  complete 
redevelopment. 

Reformatting  is  suggested  for  systems  whose  life  expectancy  is  greater  than  6  mondis 
and  less  than  three  years  (medium  life  expectancy)  and  when  the  complexity  is  medium  in  a 
system  of  little  inqrartance,  or  when  the  complexity  is  low  in  a  system  of  medium  inq)OTtance. 
Systems  with  life  expectancies  greater  than  3  years  (long  life  expectancy)  which  are  not 
conq)lex  and  are  of  little  importance  are  also  candidates  for  reformatting.  Reformatting 
primarily  serves  to  improve  maintenance  by  cleaning  up  the  appearance  of  the  source  code.  It 
does  not  alter  the  basic  software  architecture  and  requires  little  effort.  There  are  sevoal 
reformatting  tools  available,  including  language  sensitive  editors  and  pretty  printers. 

The  software  architecture  and  data  structures  are  optimized  during  the  nK>re 
complicated  process  of  restructuring.  Systems  of  medixun  life  expectancy  which  are  highly 
complex  and  of  low  to  medium  importance  are  good  candidates  for  restructuring.  Systems  of 
long  life  expectancy  that  are  not  complex  and  are  of  medium  importance  should  also  be 
restructured.  In  addition  to  restructuring,  redocumenting  is  also  a  helpful  reengineering 
process  that  extends  the  life  of  a  software  system.  Candidate  software  systems  for 
restructuring  in  conjunction  with  redocumenting  include  those  with  long  life  expectancy  that 
are  medium  to  highly  complex  with  low  importance. 

Reverse  engineering  followed  by  forward  engineering  is  the  most  time-consuming,  but 
potentially  the  most  beneficial  activity  within  reengineering.  This  activity  is  usually  limited 
to  systems  of  great  importance  to  an  organization,  since  it  is  expensive,  requiring  commitment 
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of  resources  (tools,  personnel)  to  be  successful.  Among  very  important  systems  with  medium 
life  expectancy,  regardless  of  complexity,  reverse  engineering  is  the  suggested  choice  of 
reengineering  processes.  Long  life  systems  of  medium  importance  that  are  medium  to  highly 
complex  and  long  life  systems  of  great  importance  that  exhibit  low  to  medium  complexity  are 
also  likely  candidates  for  reverse  engineering.  In  conjunction  with  reverse  engineering, 
redocumentation  is  always  suggested  for  highly  complex  systems.  Not  all  candidates  are 
appropriate  for  reengineering.  A  con^lete  redevelopment  may  be  necessary  for  the  highly 
complex,  very  important  system  which  is  expected  to  have  a  long  life. 


The  JLC  Santa  Barbara  I  Workshop 

The  JLC  Santa  Barbara  I  Workshop  generated  a  list  of  the  most  critical  criteria 
determining  when  to  reengineering  [DOD92]  (Figure  A-1).  A  candidate  application  is  rated  a 
value  1-4  as  to  how  well  the  application  meets  each  criteria. 

THE  MOST  CnmCAL  CRITERIA  OETERMININQ  WHEN  TO  REENGINEER 


CRITERIA 

1 

2 

3 

■ 

Technical  Quality 

Cost 

Complexity 

Mission  Requirements 

Importance 

PoWcal 

Ufe-Cyde  Remaining 

Change  of  Platform 

Too  Hard  to  Maintain 

Budget  Availability 

User  Satisfaction 

Maturity  Level 

Documentation  out  of 

Oate/Missing 

■ 

■ 

■ 

■ 

Reliability 

■ 

Maintenance  Change  Rate 

Design  Chartge 

nCUREA-l.  SB-1  R— nnin— ring  EconomIca  CrKIcal  Criteria. 

The  draft  Reengineering  Economics  Handbook  (MIL-HDBK-REH)  defines  a 
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Reengineering  Decision-Making  Process  that  is  based  on  the  STSC's  Reengineering  Candidate 
Selection  Process.  There  are  two  noteworthy  differences  between  the  original  STSC  Process 
and  the  Process  as  it  appears  in  the  draft  MIL-HDBK-REH.  First,  the  variable  called 
"in^rtance"  was  renamed  "environmental  ri^."  The  weighted  questions  for  this  variable  are 
essentially  the  same.  Secondly,  the  appropriate  reengineering  strategy(s)  to  follow  after 
applying  this  Process  are  presented  in  two  charts:  one  for  medium  life  expectancy  (Figure  3- 
1)  and  one  for  long  life  expectancy  (Figure  3-2).  The  Process  suggests  that  software  with  a 
remaining  life  expectancy  of  less  than  6  months  should  not  be  reengineered. 
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RGUREA-2.  Santa  Barbara  I;  Medium  Lifetime  Remaining. 
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HGUREA-3.  Santa  Barbara  I:  Long  Lifetime  Remaining. 
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Naticmal  Institute  of  Standards  and  Technology  Case  Study 

The  recommendaticnis  which  resulted  from  the  NIST  Case  Study  [Ruhl91,  plS-23] 
include  the  following: 

Establish  the  context  for  reengineering  by  considering  the  corporate  goals  of  the 
oiganizadtMi  and  how  reengineering  could  be  applied  to  achieve  this  mission. 
Information  dependencies  between  application  systems  must  be  identified  [pl5]. 

Analyze  system  requirements  from  a  functional  viewpoint  and  consider  new 
technology  to  improve  current  business  practices  [pl5]. 

When  procuring  equipment,  require  conformance  to  applicable  standards  (e.g.,  FIPS)  to 
achieve  flexibility  and  ease  in  ^ture  migrations  [pl6]. 

Identify  motivations  and  what  is  to  be  achieved  by  reengineering  [pl6]. 

Evaluate  application  system  with  the  intent  of  discovering  what  is  worth  retaining  for 
future  use  and  vdiat  is  not  [pl7]. 

Stress  data  design  because  it  will  force  modifications  to  the  process  design  [pi 7]. 

Evaluated  code,  documentation,  maintenance  history,  and  appropriate  metrics  to 
determine  the  current  condition  of  the  system  [pl9]. 

While  design  recovery  is  difficult,  time-consuming,  and  essentially  a  manual  process, 
it  is  vital  for  recovering  lost  information  and  information  transfer  [pl9]. 

Identify  critical  system  information.  Do  not  be  tightly  tied  to  a  certain  set  of 
documentation  forms;  focus  on  information  content  and  usage  [p20]. 

Provisions  in  terms  of  personnel  and  effort  must  be  made  to  compensate  for  the  lack 
of  full  support  of  the  reengineering  process  by  currently  available  off-the-shelf  tools 

[p21]. 

Considering  the  focus  of  most  CASE  tools  for  a  particular  computing  environment, 
one  set  of  CASE  tools  should  not  be  depended  on  for  uniform  applicability  to  all 
needs  across  an  organization  [p21]. 

Adequate  storage  capacity  and  processor  speed  in  equipment  supporting  the 
reengineering  tools  are  essential  to  facilitate  the  reengineering  process  [p21]. 

Consider  CASE  reengineering  tools  that  provide  methodologies  which  are  compatible 
to  the  requirements  of  the  particular  enterprise  [p21]. 
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Additional  features  that  merit  consideration  include  a  data  interchange  facility  and 
appropriate  metric  analysis  utility  [p22]. 

Reengineering  requires  a  highly  trained  staff  that  has  experience  in  the  current  and 
target  system,  the  automated  tools,  and  the  specific  programming  languages  [p22]. 

It  is  critical  that  the  {q>plicati<»i  system  experts  be  involved  throughout  the 
reengineering  process.  They  are  essential  fw  design  recovery  [p23]. 
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Peihi^s  the  best  way  to  determine  what  factors  influence  the  reengineering  process  is 
to  look  at  achial  reengineering  efforts  as  case  studies.  Only  recently  have  there  been 
reengineering  efforts  of  the  magnitude  to  produce  data  that  is  useful  in  predicting  the  success 
of  reengineering  similar  ^plications.  Scmie  of  these  efforts  have  been  documented  [Hobb91, 
Ruhl91,  MITRE92].  The  documented  reasons  for  selecting  these  software  systems  for 
reengineering  varied,  but  the  expected  benefits  listed  below  were  the  same.  A  summary  of 
the  issues  involved  in  these  case  studies  is  presetted  below. 


Reasons  for  Considering  Reengineering 

The  reasons  for  considering  reengineering  vary  from  anticipated  support  for  continued 
maintenance  to  support  for  development  of  modernized  systems.  Existing  system  are  also 
being  examined  for  consolidation,  by  commonality  among  functions  and  redundancy.  Another 
reason  for  considering  reengineenng  is  to  analyze  the  technolc^  of  reengineering  for 
determining  its  potential  benefits. 

Maintenance  support  In^roved  maintenance  was  one  reason  for  reengineering  in  many  of  the 
case  studies  examined.  Manual  processes  were  often  used  to  support  existing  systems.  It  was 
in^wrtant  to  provide  the  ability  to  respond  quickly  and  correctly  to  change  requests.  Existing 
systems  were  being  modified  more  to  keep  pace  with  the  changing  needs  of  the  users  since 
fewer  new  systems  were  being  developed.  Reoigineering  the  system  to  an  implementation 
which  is  more  maintainable  or  to  a  CASE  environment  for  automated  support  promised  to 
extend  the  life  of  the  system. 

Consolidation  of  Functionalitv.  Consolidating  functionality  across  software  systems  reduces 
maintenance  costs  by  decreasing  the  number  of  systems  to  support  and  eliminates  redundancy 
across  domains.  Many  of  the  reengineering  efforts  examined  were  performed  to  consolidate 
software  systems  within  a  single  oiganization,  as  well  as  consolidate  in  business  practice  by 
selecting  a  single  system  to  be  integrated  in  multiple  organizations  where  duplicate  systems 
were  poforming  the  same  function  in  like  domains. 

In  an  effort  to  minimize  redundancy  across  agencies,  DOD  has  begun  initiatives  to 
select  specific  software  systems  for  use  by  multiple  organizations  for  performing  the  same 
functionality.  Traditionally,  each  agency  maintained  independent  software  systems  that 
performed  functions  in  similar  domains  such  as  persormel,  billing,  and  contracts.  A  single 
software  system  is  being  selected  for  use  in  multiple  organizations  that  would  be  supported  at 
one  central  location.  The  existing  duplicate  systems  are  to  be  reengineered  for  the 
development  of  a  single  system  for  easy  transition  within  various  agencies.  These  systems 
need  to  execute  on  a  variety  of  hardware  platforms,  including  personal  computers  and 
mainframes.  Support  for  these  systems  needs  to  handle  a  greater  volmne  of  change  requests 
since  they  will  be  handled  by  one  central  location  servicing  a  larger  number  of  organizations. 
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Confomnanre  tn  StanHarHs  New  Standards  in  software  engineering  provide  for  the 
develt^ment  of  improved  software  systems.  Reengineering  was  being  performed  in  many 
cases  to  enable  existing  systems  to  conform  to  these  new  standards  as  if  they  had  been 
developed  using  them.  Hiese  standards  include  implementation  using  the  Ada  programming 
language  and  open  systems  environments  (POSIX).  Introducing  new  standards  to  ^e  existing 
system  promised  to  extend  the  life  of  these  systems  and  prepare  for  future  migration. 

New  Software  System  Development.  Many  of  the  reengineering  efforts  examined  were 
performed  to  achieve  new  system  requirements.  Previous  common  practice  would  have 
developed  a  brand  new  software  system;  reengineering  would  utilize  as  much  existing 
software  as  possible,  while  improving  the  performance  and  enhancing  the  fimctionality  to 
meet  these  new  requirements.  The  inability  to  develop  new  software  systems  due  to 
decreasing  budgets  was  overcome  by  reverse  engineering  existing  systems  to  CASE  and 
regenerating  more  modem  software  systems  that  would  adhere  to  modem  standards. 

Technology  analysis.  Technology  analysis  can  be  facilitated  by  actually  applying  interim 
technological  advances  to  determine  the  benefits  and  examine  alternative  solutions.  This 
analysis  is  often  too  costly  for  many  organizations,  although  it  would  ease  technology 
transition  by  providing  proof-of<concept.  Research  organizations  often  sponsor  pilot  projects 
or  case  studies  using  mock  applications  to  provide  proof-of-concept  and  to  assess  the  benefits 
of  a  maturing  technology.  Several  of  the  reengineering  efforts  examined  as  case  studies  for 
developing  the  Criteria  were  analyzing  the  technology  of  reengineering  to  determine  its 
potential  benefits.  Software  applications  were  selected  to  reengineer  which  were 
representative  of  other  projects  in  the  organization;  these  applications  had  similar 
functionality,  were  written  in  the  same  programming  languages,  and  executed  on  the  hardware 
platforms  from  which  many  systems  were  migrating.  The  candidate  applications  were  often 
much  smaller  than  their  representative  systems,  and  although  this  facilitated  the  reengineering 
effort,  it  was  unclear  as  to  whether  the  resulting  data  would  scale  up  for  larger  software 
systems  [Hobbs92].  The  size  of  a  software  system  is  often  detrimental  to  the  success  of  any 
software  engineering  effort  by  impacting  cost,  scheduling,  and  the  utilization  of  resources. 
Reengineering  is  no  different. 


Case  Study  Data  Summary 

Case  study  data  diowed  that  most  of  the  software  systems  had  similar  characteristics. 
The  existing  systems  were  primarily  written  in  the  Common  Business  Oriented  Language 
(COBOL),  witii  small  amounts  of  hardware-dependent  assembly  language.  There  was  usually 
some  in-house  method  for  performing  data  management.  The  hardware  platforms  ranged 
from  personal  computers  to  mainframe  computer.  The  sizes  overall  ranged  from  ten 
thousand  to  over  one  million  lines  of  source  code,  although  in  the  cases  of  the  larger  systems, 
it  was  often  only  a  portion  of  the  software  that  was  to  be  reengineered. 
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The  target  sofitware  was  the  Ada  programmijig  language,  and  the  desire  to  incorporate 
COTS  wherever  possible  and  to  integrate  with  a  commercial  database  management  system. 
The  target  platform  was  often  a  workstation  envirrmment,  although  more  often  there  was  a 
need  to  support  multiple  or  unknown  platforms.  This  was  to  be  achieved  through  an  open 
systems  enviroiunent  with  POSIX.  The  target  system  needed  to  be  adaptable  to  future 
modifications  with  additional  or  alternative  hardware  platforms,  while  reliably  performing  its 
required  functionality. 


Suggested  Data  to  be  Collected  in  Future  Efforts 

Ideally,  an  organization  that  is  about  to  begin  a  reengineering  effort  should  gather  data 
as  the  effort  progresses.  This  data  should  be  sent  to  the  authors  of  this  report  for  further 
refinement  of  the  Criteria  and  should  be  used  in  their  own  orgaiuzations  to  predict  the  success 
of  reengineering  efforts  on  similar  software  systems. 
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TABLE  I.  SOFTWARE  CHARACTERISTICS 


Software  Characteristics 

Description  | 

Complexity 

software  constructs  (conditionals,  iterations, 
statements),  calls  to  external  routines,  and  I/O 

Data  structure 

variables,  constants,  complex  structures  (records, 
linked  lists),  user-defined  constructs 

Lar>guages 

number  of  implementation  languages  and  defined 
grammars  for  each 

Modularity 

defined,  unique  furxrtionality  in  each  module 

Size 

SLOC,  function  points,  number  of  modules/objects, 
bytes,  number  of  files 

Software  change  rate 

average  number  of  modifications,  both  corrective  and 
perfective,  over  a  given  period  of  time 

Software  importance 

number  of  people/organizations  serving,  number  of 
external  systems  interfacing,  times  accessed  per 
day/month,  life-threatening;  function  not  offer^  by  any 
other  system  in  parent  organization,  or  other  known 
organization 

Structural  quality 

an  analysis  of  the  structure  of  the  software  system,  i.e, 
missing  code,  work-arounds. 

TABLE  11.  SYSTEM  CHARACTERISTICS 


System  Characteristics 

Description 

Alternate  configurations 

whether  or  not  there  are  alternate  configurations  of  this 
system;  if  so.  a  description  of  these  configurations  and 
scenarios  for  when  each  is  an  alternative 

Commercial  software  interface 

number  of  commercial  software  packages  that  interface; 
and  a  description  of  that  interface 

Requirement  obsolescence 

to  what  degree  the  system  requirements  are  no  longer 
viable;  which  requirements  are  viable 
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TABLE  III.  ENVIRONMENT  CHARACTERISTICS 


1  Environment  Characteristics 

Description 

Domain  consistency 

whether  or  not  the  system  exists  within  a  domain  and 
the  description  of  that  domain;  whether  or  not  the 
system  needs  to  fit  within  a  domain  and  a  description 
of  that  domain 

Hardware  interface 

definition  of  the  hardware  upon  which  the  system 
depends  and  a  description  of  this  interface;  whether  or 
not  the  system  can  reside  on  more  than  one 
hardware/software  platform;  identification  and 
description  of  those  platforms  if  currently  residing  on 
more  than  one 

Organizational  goals 

describes  the  high  level  goal(s)  of  the  organization 
relative  to  this  software  system  and  the  function  this 
system  plays  in  accomplishing  this  goal(s). 

Usage 

number  and  type  of  interactions  with  the  system  by 
individuals,  other  organizations,  and  external 
automated  systems 

TABLE  IV.  DEVELOPMENT  FACTORS 


i 

1  Development  Factors 

Description 

1  Design 

whether  or  not  the  design  is  complete  to  source  code;  if 
not,  identification  of  missing  parts  or  extent  of 
incompleteness;  whether  or  not  the  design  is  consistent 
vrith  the  source  code;  if  not,  identification  of 
inconsistency 

Development  methodology 

whether  or  not  a  well-defined  development  procedure 
was  used;  whether  it  is  documented  in  text  available  to 
the  public;  wriiether  or  not  this  methodology  is  supported 
by  automation 

Documentation 

supplemental  documents  including  reports,  tables,  user 
guides  which  describe  aspects  of  the  system  not 
necessarily  relating  to  design 

Standardization 

use  of  well-documented  development  standards, 
continued  throughout  maintenance 
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TABLE  V.  MAINTENANCE  FACTORS 


Maintenance  Factors 

Description 

Automation 

whether  or  not  an  automated  process  is  used  for 
modifications 

Configuration  man^ement 

a  management  process  for  controlling  and  documenting 
modifications  and  versions  of  the  software  system 

Improvement  status 

to  what  degree  the  system  could  be  improved  to  meet 
the  organizational  goals;  description  of  these 
improvements:  to  what  degree  the  system  could  be 
improved  to  meet  current  known  requirements  efficiently 

Life  expectancy 

amount  of  time  this  system  is  expected  to  be  in 
existence 

Modification  effort  (MJ 

rate  of  modification  over  number  of  modifications  times 
the  average  number  of  maintainers  to  complete  (M,  - 
Af/n*m). 

Modification  rate  (M,) 

number  of  modifications  per  a  given  period  of  time 
relative  to  a  desired  number 

TABLE  VI.  TARGET  SOFTWARE  CHARACTERISTICS 


Target  Software  Characteristics 

Description 

Functional  improvement 

number  and  type  of  functional  modifications  which 
desired  ir. , mallei  to  the  reengineering  of  this  system; 
test  suite  for  verifying  these 

Language  migration 

identification  and  description  of  the  language 
implementation  requested  for  this  system 

Performance  improvement 

identification  and  description  of  the  desired  performance 
improvements  for  this  system;  test  suite  for  validating 
these 

Technology  insertion 

identification  of  specific  technological  advances  that 
could  be  implemented  to  improve  the  software  system, 
including  new  commercial  packages 
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TABLE  VII.  NEW  SUPPORT  CHARACTERISTICS 


New  Support  Characteristics 

Description  | 

Adaptability 

to  what  extent  the  new  support  environment  will  enable 
the  software  system  to  adapt  to  a  changing 
environment,  i.e.,  enhancements,  alternate  software/ 
hardware  implementations,  integration  of  new 
components 

Automation  insertion 

desire  to  maintain  the  software  system  using  automated 
techniques 

Domain  consistency 

to  what  extent  the  new  support  environment  supports 
other  systems  in  the  same  domain 

Maintenance  improvement 

identification  and  description  of  specific  improvements  to 
the  overall  maintenance  process;  to  what  degree  the 
current  maintenance  practices  are  no  longer  useful; 
description  of  the  problems 

TABLE  Vlll.  NEW  ENVIRONMENT  CHARACTERISTICS 


H  New  Environment  Characteristics 

Description 

1  Domain  insertion 

identification  and  description  of  the  new  target  domain 

1  New  hardware  platforms 

number  and  type  of  hardware  interfaces  which  are  to  be 
integrated  to  this  system;  identification  and  description 
of  alternative  or  new  hardware  platforms 

1  New  Usage 

new  people,  organizations,  or  automated  systems  that 
must  now  interface  with  this  software  system 

1  New  organizational  goals 

new  organizational  goal(s)  that  must  be  addressed  by 
this  software  system  and  how 
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TABLE  IX.  ORGANIZATION  FACTORS 


Organization  Factors 

Description 

Budget  constraints 

budget  limitation  and  predicted  allocation  of  this  amount 
to  various  resources  and  phases  of  the  intended 
reengineering  activity(s) 

Effort  estimations 

projected  estimations  regarding  manpower  and  time  for 
performing  the  reengineering  activity(s) 

Management  commitment 

definition  of  management  expectations  and  limitations; 
schedule  for  identification  of  management  objectives 
and  proof  of  progress  throughout  the  reengineering 
activity(s) 

Schedule 

establish  management  approved  schedule  for 
performing  the  reengineering  activity(s),  including 
alternative  plans  based  on  trade-offs  measured 
throughout  the  activity 

TABLE  X.  METHODOLOGY  FACTORS 


Methodology  Factors 

Description 

Automation  support 

automated  support  for  the  methodology  selected  to 
perform  the  reengineering 

Forward  engineering  support 

to  what  extent  the  reengineering  tools  support  the 
forward  engineering  processes;  identification  and 
description  of  the  interfaces  to  these  processes 

Methodology  selection 

identify  and  select  a  well-defined  methodology;  insure 
training  is  available  and  that  the  methodology  meets  the 
goals  of  the  organization;  insure  that  the  methodology  is 
usable  across  domains  and  in  support  throughout  the 
maintenance  process 

Reuse  commitment 

investigate  reuse  options  whenever  possible 
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TABLE  XL  AUTOMATION  FACTORS 


Automation  Factors 

Description 

Capability  limitations 

limitations  on  use  of  tool,  i.e.,  maximum  number  of 
users,  limitations  on  methodology  support 

Platform  support 

insure  ttiat  hardware/operating  systems  and  integration 
to  existing  or  selected  reengineering  platform 
environment;  identification  of  platforms  supporting  tools 
and  the  limitations  of  this  support 

Target  hardware  support 

relationship  of  tool  to  hardware  platform  of  reengineered 
product  ( does  the  target  hardware  itself  support  the 
tool,  does  the  tool  support  the  development  of  software 
for  the  target  hardware) 

Tool  availability 

does  the  tool  currently  exist  in  the  organization,  is  the 
organization  capable  of  acquiring  this  tod, 
understanding  the  cost  and  time  for  procurement 

TABLE  Xll.  PERSONNEL  FACTORS 


1  Personnel  Factors 

Description  1 

1  Existing  system  expertise 

personnel  with  the  expertise  on  the  functionality, 
operations,  and  performance  of  the  existing  system  and 
are  committed  to  the  reengineering  effort 

Target  system  expertise 

personnel  with  the  expertise  on  the  desired  functionality, 
operations,  and  performance  of  the  target  software 
system  and  are  committed  to  the  reengineering  effort 

Reengineering  expertise 

personnel  with  the  expertise  on  the  methodology  and 
automated  tools  for  performing  the  reengineering 
activity(s)  and  are  committed  to  the  reengineering  effort 
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APPENDIX  E 


SOFTWARE  REENGINEERING  CRITERIA  QUESTIONNAIRE 
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SOFTWARE  REENGINEERING  CRITERIA  QUESTIONNAIRE 


The  following  questionnaire  documents  data  that  is  usejul  in  identifying  candidate  information 
systems  for  software  reengineering.  Please  answer  the  following  questions. 

I.  Existing  Software  System  Criteria  (Existing  Software  System  Criteria  is  composed  of 
product  characteristics  that  describe  the  existing  software  system,  the  environment  in  which  it 
operates,  and  process  factors  which  influenced  the  development  and  maintenance  of  the 
system.) 

A.  Product  Characteristics  (Product  characteristics  describe  the  software  system, 
including  software  characteristics  and  system  characteristics,  and  the  characteristics 
describing  the  environment  in  which  each  system  operates.) 


1.  Software  Characteristics  (Software  characteristics  describe  the  source  code  of  the 
system.) 

-  What  is  the  complexity  of  the  software?  (identify  those  modules  with  highest 
complexity  for  additional  examination) 

-  What  is  the  data  structure  used  in  the  software? 

-  What  programming  languages  are  used  to  implement  the  software? 

-  Is  there  modularity  in  the  software?  Do  modules  perform  identifiable  functions 
or  display  specific  behavior? 

-  What  is  the  size  of  the  software?  (How  many  lines  of  source  code/function 
points?) 

-  What  is  the  software  change  ratel  (The  number  of  modifications  made  over  a 
given  period  in  time) 

-  What  is  the  software  importance!  (Number  of  times  each  software  is  accessed 
in  a  given  period  of  time;  is  the  software  fimctionality  life-threatening;  does  the 
software  perform  some  function(s)  not  performed  anywhere  else  in  the 
oiganization?) 

-  What  is  the  structural  quality  of  the  software?  (Is  there  missing  code  or  "dead” 
code  that  is  never  executed;  is  there  evidence  of  work-arounds  that  modify  the 
software) 

2.  System  Characteristics  (System  characteristics  describe  any  commercial  or  external 
software  packages  that  integrate  with  source  code  to  meet  system  requirements.) 

-  Are  there  alternate  configurations  of  each  software  and  what  are  the  conditions 
for  which  these  exist? 

-  What  commercial  software  interface  does  the  system  contain?  (e.g.,  DBMS  and 
X-Windows) 

-  Are  existing  requirements  obsolete  or  need  change? 
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3.  Environment  Characteristics  (Environment  characteristics  describe  the 
organization's  primary  /unctions  with  respect  to  how  the  software  system  operates.) 

-  Are  there  domain  consistencies  which  must  be  maintained  by  each  system? 

-  What  is  the  hardware  interface  for  each  software  system?  (Is  there  a  strcmg 
relationship  between  hardware  and  software?  Is  the  current  software  portable  to 
other  hardware  platforms?) 

-  What  organizadorud  goals  do  these  software  systems  address  and  how? 

-  What  is  the  usage  of  the  software?  How  many  users  are  there  for  each 
system?  How  many  individuals,  organizations,  or  automated  systems  use  each 
system?) 

B.  Process  Factors  (Process  factors  describe  the  aspects  of  the  original  development 
process  and  the  maintenance  process  which  have  impacted  the  current  implementation  of 
the  software  system.) 

1.  Development  Factors  (Development  factors  define  aspects  of  the  development 
process  which  have  affected  the  software  system  implementation.) 

-  Docs  a  high  level  desigp  of  the  software  exist?  (Is  the  available  design 
complete  with  respect  to  the  current  software?  Is  the  available  design  consistent 
>vith  respect  to  the  current  software?) 

-  What  development  methodology  was  followed?  (Were  structured  methodologies 
or  some  type  of  well-defined  and  documented  methodology  utilized?) 

-  What  supporting  documentation  exists? 

-  What  standardization  principles  were  used  in  the  development  of  the  software? 

2.  Maintenance  Factors  (Maintenance  Factors  define  aspects  of  the  development 
process  which  have  affected  the  software  system  implementation.) 

-  Is  the  maintenance  process  supported  by  automation! 

-  Is  any  form  of  configuration  management  employed  in  maintenance  process? 

-  What  is  the  improvement  status  of  the  software?  (Is  the  system  status  regarded 
as  one  of  improvement  or  decline?  Is  the  current  system  defective?) 

-  What  is  the  life  ejqrectancy  of  each  system?  How  long  is  each  system  expected 
to  operate? 

-  What  is  the  modification  effort)  (How  many  labor  hours  are  spent  modifying 
the  system?) 

-  What  is  the  modification  rate!  (How  often  is  the  system  modified?) 
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U.  Reengineered  Software  System  Criteria  (Reengineered  Software  System  Criteria  include 
those  criteria  which  describe  the  desired  products  of  the  reengineering  process  and  the 
factors  which  influence  the  reengineering  process.) 

A.  Reengineering  Product  Characteristics  (Reen^neering  Product  Characteristics  describe 
the  desired  characteristics  of  the  new  target  software,  the  new  support  environment  and 
the  environment  in  which  the  software  will  be  operating.) 

1.  Target  Software  Characteristics  (Target  Software  Characteristics  describe  the 
modifications  that  are  desired  between  the  existing  software  and  the  new  software.) 

-  Will  the  system  be  Junctionally  improved!  (Are  new  flmctional  requirements 
being  added?) 

-  Is  there  a  desire  to  miff'ate  to  another  language! 

•  Will  the  performance  of  the  system  be  improved!  (Will  new  poformance 
requirements  be  introduced?) 

-  Can  technology  insertion  improve  the  software  system?  Are  new  technologies 
available  that  would  greatly  improve  system  implementation? 

2.  New  Support  Characteristics  (New  support  characteristics  define  the  qualities 
desired  in  a  new  maintenance  process. 

-  Is  the  goal  to  make  the  system  adaptable! 

-  Is  there  a  desire  to  automate  the  maintenance  process? 

-  Is  the  goal  to  make  the  system  domain  consistent! 

-  Is  there  a  desire  to  improve  the  maintenance  process  or  change  to  a  new  or 
different  automated  support  environment? 

3.  New  &ivironment  Characteristics  (New  Environment  Characteristics  describe  the 
new  operational  environment  to  which  the  existing  system  must  migrate.) 

-  Is  there  a  desire  to  insert  systems  into  a  new  domain! 

-  Initially,  is  there  a  desire  to  move  to  another/multiple  new  hardware  platforms! 

-  Are  new  users  of  the  system? 

-  Is  there  a  new  organizational  goal  to  which  each  software  system  must  adhere? 
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B.  Reengiiieaing  Process  Factors  (Reengineaing  Process  Factors  define  the  influence  of 
the  organizational  goals,  reengineering  methodology,  and  the  available  resources.) 

1.  Organizatiini  FacUws 

-  Are  there  budget  constraints  in  v^ch  to  perfOTm  reengineering? 

-  Have  effort  estimations  been  made  as  to  the  schedule  and  effint  of  the 

reengineering?  (including  personnel,  tools,  training,  operating,  post- 

implementatirm  costs,  reengineering) 

-  Is  management  committed  to  renewing  these  systems?  Which  ones? 

-  Are  there  schedules  to  adhere  to? 

2.  Methodology  Factors 

-  Is  there  automation  support  ftx'  the  methodology  selected? 

-  Does  the  methodology  selected  link  to  the  forward  engineering  environment? 

-  Has  a  methodology  for  reengineering  already  been  selected^ 

-  Is  there  a  reuse  commitment  to  introduce  reusable  components  into  the  system 

wherever  possible? 

3.  Resource  Factors 

a.  Automation  Factors 

-  Are  there  capability  limitations  in  the  available  tools  for  reengineering? 

•  Is  there  reengineering  hardware  platform  available  to  support  tools,  system 
data,  and  the  reengineering  process? 

-  Are  there  reengineering  tools  that  support  the  development  of  software 
systems  for  the  target  hardware(s)  of  the  reengineered  system  (if 
applicable)? 

-  Are  these  tools  available  in  the  organization  currently  or  will  they  have  to 
be  procured? 

b.  Persoimel  Factors 

-  Are  there  personnel  available  \riio  have  existing  system  e:q>ertise  in  the 
operations,  functions,  and  performance  of  the  software  system  are 
available  to  work  cm  the  reengineering  effort? 

-  Are  there  personnel  available  who  have  target  system  expertise  in  the 
operatirms,  functions,  and  performance  of  the  target  software  system  are 
available  to  work  on  the  reengineering  effort? 

-  Are  there  personnel  who  have  reengineering  expertise  and  are  familiar  with 
the  selected  tools? 
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F-1 


The  following  example  application  of  the  Software  Reengineering  Criteria  uses  data  from  a 
typical  software  engineering  environment  (SEE)  for  information  systems  within  DOD.  The 
exan^>le  begins  by  documenting  the  candidate  SEE  using  the  Software  Reengineering  Criteria 
Questionnaire  (Appendix  E  SOFTWARE  REENGINEERING  CRITERIA 
QUESTIONNAIRE),  followed  by  the  ^plication  of  the  criteria  resulting  in  a  reengineering 
strategy,  and  a  comparison  of  the  application  results  to  an  actual  reengineering  effort  within  a 
similar  SEE  as  proof-of-concept  for  the  Criteria. 


5.1  Answering  the  Software  Reengineering  Criteria  Questionnaire.  The  Software 
Reengineering  Criteria  Questionnaire  was  answered  below  using  the  available  data  concerning 
typical  information  systems  agencies  within  DOD. 


I.  Existing  Software  System  Criteria 
A.  Product  Characteristics 

1.  Software  Characteristics 

•  What  is  the  complexity  of  the  software?  (identify  those  modules  with  highest  complexity  for 
additional  examination)  average  system  is  estimated  between  10  and  20  using 
Cyclomatic  complexity  method\  between  5  and  10  for  Essential  complexity^ 

•  What  is  the  data  structure  used  in  the  software?  data  design  based  on  physical 
components  of  the  computer  system 

-  What  programming  languages  are  used  to  implement  the  software?  COBOL>74 

-  Is  there  modularity  in  the  software?  Do  modules  perform  identifiable  functions  or  display 
specific  behavior?  unknown 

•  What  is  the  size  of  the  software?  (How  many  lines  of  source  code/function  points?)  100-150 
778KSLOC  per  software  system  across  multiple  programs 

-  What  is  the  software  change  rate?  (The  number  of  modifications  made  over  a  given  period 
in  time)  average  of  3  per  month  per  system 

•  What  is  the  software  importance?  (Number  of  times  software  is  accessed  in  a  given  period 
of  time;  is  the  software  functionality  life-threatening;  does  the  software  perform  some 
function(s)  not  performed  anywhere  else  in  the  organization?)  there  are  several  systems 
that  perform  unique  functions,  loss  of  one  of  these  system  would  be  very  damaging 
to  the  organization 

-  What  is  the  structural  quality  of  the  software?  (Is  there  missing  code  or  ”dead"  code  that  is 
never  executed;  is  there  evidence  of  work-arounds  that  modify  the  software?)  evidence  of 
patches  in  many  systems,  poorly  structured  in  most  cases 

2.  System  Characteristics 

-  Are  there  alternate  configurations  of  software  and  what  are  the  conditions  for  which  these 
exist?  no 

-  What  commercial  software  interface  does  the  system  contain?  (e.g.,  DBMS  and  X-Windows) 

none 

-  Are  existing  requirements  obsolete  or  need  change?  not  at  this  time 

3.  Environment  Characteristics 

-  Are  there  domain  consistencies  which  must  be  maintained  by  each  system?  no 

-  What  is  the  hardware  interface  for  each  software  system?  (Is  there  a  strong  relationship 
between  hardware  and  software?  Is  the  current  software  portable  to  other  hardware 
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platforms?)  Honeywell  DPS-8000  computer,  software  Is  not  portable 

-  What  organizations^  goals  do  these  software  system  address  and  how? 

What  is  the  usage  of  the  software?  How  many  users  are  there  for  each  system?  How  many 
individuals,  organizations,  or  automated  systems  use  each  system?)  tape  interface  with 
several  external  software  systems;  tape  intertace  with  several  devices,  including  HP 
1000>A  minicomputer  and  a  NCS  Westlnghouse  Scanner;  system  is  on-line 

B.  Process  Factors 

1.  Development  Factors 

-  Does  a  high  level  design  of  the  software  exist?  (Is  the  available  design  complete  with 
respect  to  the  current  software?  Is  the  available  design  consistent  with  resp^  to  the  current 
software?)  data  requirements  for  each  system  existed  when  it  was  built,  but  were 
never  documented. 

-  What  development  methodology  was  followed?  (Were  structured  methodologies  or  some 
type  of  well-^fined  and  documented  methodology  utilized?)  no  standard  procedure 

-  What  supporting  documentation  exists?  very  little 

-  What  standardization  principles  were  used  in  the  development  of  software?  unknown 

2.  Maintenance  Factors 

-  Is  the  maintenance  process  supported  by  automatiorfl  no  automation,  manual  data 
management  facilities 

-  Is  any  form  of  configuration  management  employed  in  maintenance  process?  unknown 

•  What  is  the  improvement  status  of  the  software?  (Is  the  system  status  regarded  as  one  of 
improvement  or  decline?  Is  the  current  system  defective?)  maintenance  back-log  which  is 
increasing  for  at  least  one  system,  ever-increasing  user  demands  mean  there  are 
several  systems  that  are  becoming  outdated,  system  quality  is  relatively  remaining 
the  same 

-  What  is  the  life  expectancy  of  each  system?  How  long  is  each  system  expected  to  operate? 
indefinite,  the  functionality  of  these  systems  will  be  continuously  required 

-  What  is  the  modification  efforfl  (How  many  labor  hours  are  spent  modifying  the  system?) 
more  than  32  hours  per  month  average,  maintainers  have  expressed  general  difficulty 
in  making  software  changes 

-  What  is  the  modification  rate?  (How  often  is  the  system  modified?)  unknown 


II.  Reengineered  Software  System  Criteria 
A.  Product  Characteristics 

1.  Target  Software  Characteristics 

-  Will  the  system  be  functionally  improverP  (Are  new  functional  requirements  being  added?) 

not  at  this  time 

-  Is  there  a  desire  to  migrate  to  another  language?  Ada  and  4GL 

-  Will  the  performance  of  the  system  be  improved^  (Will  new  performance  requirements  be 
introduced?)  better  response  to  user  requests  is  needed 

-  Can  ter^nology  insertion  improve  the  software  system?  Are  new  technologies  available  that 
would  greatly  improve  system  implementation?  yes,  DBMS 

2.  New  Support  Characteristics 

-  Is  the  goal  to  make  the  system  adaptable?  yes  (future  migrations  are  anticipated  for 
each  system) 

-  Is  there  a  desire  to  automate  the  maintenance  process?  yes 

-  is  the  goal  to  make  the  system  domain  consistenP  migrate  these  systems  towards 
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DISA/CIM  information  systems  domain 

-  Is  there  a  desire  to  improve  the  maintenance  process  or  change  to  a  new  or  different 
automated  support  environment?  yes,  current  maintenance  organization  is  declining: 
there  is  a  need  to  reduce  current  maintenance  costs,  improve  data  management,  arul 
ease  modification  effort 

3.  New  Environment  Characteristics 

-  Is  there  a  desire  to  insert  systems  into  a  new  domaitfi  none  at  this  time 

•  Initially,  is  there  a  desire  to  move  to  another/muttiple  new  hardware  platforms!  yes,  AT&T 
B32  processor  and  others,  ail  running  Unix 

-  Are  there  new  users  of  the  system?  none  at  this  time 

-  Is  there  a  new  organizational  goal  to  which  each  software  system  must  SKjhere?  prepare  for 
future  integration  with  OiSA/CiM  information  systems,  need  to  better  express  the  data 
requirements  of  the  business  environment 

B.  Process  Factors 

1.  Organization  Factors 

-  Are  there  budget  constraints  in  which  to  perform  reengineering?  unknown 

-  Have  effort  estknations  been  made  as  to  the  schedule  and  effort  of  the  reengineering? 
(induding  personnel,  tools,  training,  operating,  post-implementation  costs,  reengineering) 

unknown 

-  Is  managemenfcornmMied  to  renewing  these  systems?  unknown  Which  ones? 

-  Are  .  ere  schedules  to  adhere  to?  none  at  this  time 

2.  Methodology  Factors 

-  Is  there  automation  support  for  the  methodology  selected?  Bachman  COBOL  Capture  and 
Data  Analyst  tools 

-  Does  the  methodology  selected  link  to  the  forward  engineering  environment?  DOD*STD* 
2167A  will  be  followed 

•  Has  a  methodology  for  reengineering  already  been  selected?  reverse  engineering  and 
forward  engineering 

-  Is  there  a  reuse  commitment  to  introduce  reusable  components  into  the  system  wherever 
possible?  unknown 

3.  Resource  Factors 

a.  Automation  Factors 

Are  there  capability  limitations  in  the  available  tools  for  reengineering?  none  at  this 
time 

Is  there  reengineering  hardware  platform  available  to  support  tools,  system  data,  and 

the  reengineering  process?  Dec  5100/Ultrix,  Personal  Computers 

Are  there  reengineering  tools  that  support  the  development  of  software  systems  for  the 

target  hardware's)  of  the  reengineered  system  (if  applicable)?  unknown 

Are  these  tools  available  in  the  organization  currently  or  will  they  have  to  be  procured? 

some  currently  available,  but  were  procured  for  this  effort 

b.  Personnel  Factors 

Are  there  personnel  available  who  have  existing  system  expertise  in  the  operations, 
functions,  and  performance  of  the  software  system  aosl  are  available  to  work  on  the 
reengineering  effort?  yes:  it  is  understood  that  expert  domain  knowledge  is 
imperative  to  capturing  the  domain  knowledge  and  at  some  of  the  systems  have 
experts  available  to  form  redesign  groups 
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Are  there  personnel  available  wvho  have  target  system  expertise  in  the  operations, 
functions,  and  performance  of  the  target  software  system  are  available  to  work  on 
the  reengineering  effort?  yes:  Redesign  groups,  contractors,  and  DISA/CIM 
Are  there  personnel  who  have  reengineering  expertise  and  are  familiar  with  the  selected 
tools?  some:  training  is  required  for  specific  tools;  contractors  and  DISA/CiM  have 
reengineering  experience 


5.2  Suggested  Reeneinecrine  Strategy  Based  on  Criteria.  The  suggested  reengineering 
strategy  based  on  the  criteria  is  derived  through  the  following  process.  Each  question  in  the 
questionnaire  relates  to  a  specific  criteria  that  is  highlighted  in  the  text  of  the  question.  The 
definition  of  each  criteria  is  obtained  from  Section  4  and  examined  using  the  answer  to  the 
question.  This  examination  extracts  the  relevant  text  from  the  definition  based  on  the  answer 
to  the  question.  From  the  relevant  text  references  to  the  application  of  the  specific 
reengineering  capabilities  as  defined  in  Section  2  are  extracted  and  then  combined  across 
criteria  and  finally  consolidated  to  eliminate  any  redundant  text.  The  reengineering  strategy  is 
then  presented  ba^  on  these  capabilities.  It  is  important  that  specific  methodologies  [for 
these  capabilities]  be  chosen  that  are  compatible  with  the  requirements  of  the  organization  and 
are  supported  by  automation  where  possible  [Ruhl91,  p21].  The  reengineering  strategy  for  the 
example  utilizes  redocumentation,  restructuring,  and  reverse  engineering  with  forward 
engineering  techniques. 

Since  several  software  systems  in  this  SEE  are  likely  to  benefit  from  varying 
reengineering  techniques,  it  is  probable  that  one  system  should  be  chosen  that  is 
representative  of  the  others  for  a  first  reengineering  effort.  The  system  should  also  exhibit 
some  of  the  unique  qualities  of  the  systems  documented  in  the  answers  to  the  questions  above 
as  possible.  For  example,  it  was  stated  that  some  of  the  software  systems  interfaced  with 
external  software  systems  and  hardware  devices.  It  was  also  stated  that  a  limited  number  of 
systems  had  persormel  available  with  system  expertise.  A  candidate  system  should  be 
selected  which  has  at  least  one  interface  to  an  external  software  system  and  one  to  a  hardware 
device.  Persormel  with  the  expertise  on  this  system  should  also  be  available  to  confer  during 
the  reengineering  process. 

Redoemnentation  should  be  used  to  provide  insight  into  the  current  structure  of  the 
data,  generating  tables  of  variable  names,  and  usage.  The  data  structure  criteria  determined 
that  the  software  systems  in  the  example  SEE  contained  data  design  that  was  based  on  the 
physical  components  of  the  computer  system.  Steps  should  be  taken  to  rename  data  to  more 
informative  terms.  Documentation  supports  reverse  engineering  by  providing  supplemental 
information  that  is  useful  in  distinguishing  design  and  requirements  information  from 
implementation  idiosyncracies  for  improving  portability.  Redocximenting  the  software  using 
an  automated  tool  can  provide  fast  information  about  the  software  architecture  that  can  be 
maintained  along  with  the  system.  The  design  and  documentation  criteria  determined  that 
there  was  little  supplemental  representations  of  the  software  systems. 
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Restructuring  the  data  model  and  software  architecture  may  better  prepare  the  software 
for  future  modifications.  The  structural  quality  criteria  suggests  that  these  can  be  improved. 
However,  the  longer  the  system  is  expected  to  be  in  service,  the  more  likely  it  is  that  the 
entire  system  should  probably  be  reverse  engineered.  The  life  expectancy  criteria  states  that 
this  system  is  expected  to  remain  in  use  for  an  extended  period  of  time.  Older  systems  that 
are  still  relied  upon  for  their  functionality  will  probably  continue  to  serve  a  useful  function  in 
the  future  and  should  be  moved  to  a  more  maintainable,  survivable  status.  During 
restructuring  existing  system  experts  should  be  used  to  verify  that  this  process  is  not  altering 
the  functionality  of  the  software  system  (during  restructuring,  existing  and  target  system 
expertise  are  usually  the  same  individuals  since  only  the  performance  aspects  of  the  system 
are  altered  and  flmctionality  remains  the  same).  During  restructuring,  target  software  experts 
insure  that  performance  has  been  improved.  The  existing  system  expertise  and  target  system 
expertise  criteria  suggest  that  personnel  possessing  this  expertise  are  available  to  perform 
these  tasks,  thus  improving  the  likelihood  of  success  in  reengineering. 

Revo^  engineering  the  data  model  and  integrating  an  efficient  data  management 
facility  will  provide  the  biggest  payoff  for  this  information  system.  Reverse  engineering  can 
salvage  an  existing  software  design,  which  can  then  be  restructured  and  reimplemented  into  a 
more  riKxlem  software  system  that  utilizes  advanced  software  engineering  technology.  The 
lack  of  current  designs  as  suggested  by  the  design  criteria  supports  the  generation  of  such 
representations.  Reverse  engineering  the  data  models  from  the  software  and  incorporating  a 
commercial  database  may  improve  data  management  as  suggested  by  the  technology  insertion 
criteria.  Improved  naming  conventions  can  be  achieved  when  reimplementing  to  a  new 
programming  language  that  does  not  limit  the  designation  of  variables  by  length  or  characters, 
and  permits  extended  structures.  Migration  to  advanced  hardware  platforms  also  can  affect 
data  naming  and  structure  conventions,  often  enabling  greater  memory  capacity.  Poorly 
structured  software  is  candidate  for  reverse  engineering  to  a  design  representation  that  can 
then  be  restructured.  Time  may  be  wasted  on  analyzing  and  reverse  engineering  dead  code 
that  is  of  no  value  to  the  software.  Steps  should  be  taken  to  manually  parse  through  the  code 
to  eliminate  unnecessary  code.  During  forward  engineering  target  software  experts  are 
consulted  to  insure  the  new  system  meets  all  requirements,  including  functional  and 
performance. 

Reverse  engineering  the  software  into  a  CASE  tool  will  help  integrate  automation  into 
the  maintenance  process.  Modernizing  the  system  promises  to  improve  system  performance 
as  well  as  the  response  time  of  maintainers  to  change  requests  from  the  users.  Reverse 
engineering  and  regeneration  of  the  software  may  be  useful  in  generating  a  new  software 
system  for  the  new  hardware.  Reengineering  is  often  used  to  modernize  the  software  to  a 
implementation  that  is  better  suited  for  future  migrations  [MITRE92].  Eliminating  hardware 
dependencies  when  using  the  recovered  design  in  a  new  implementation  may  make  the 
software  more  portable  for  future  migrations  to  new  or  alternative  hardware  platforms. 
Retisable  components  may  be  incorporated  into  the  existing  system  to  replace  outdated 
components  and  improve  the  performance  of  the  software.  Reverse  engineering  the  software 
into  a  CASE  tool  may  facilitate  the  generation  of  implementations  in  alternative  languages. 
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Reverse  engineering  lo  a  high  level  design  and  then  regenerating  the  software  in  Ada  is 
another  option.  During  reverse  engineering  and  redocumentation,  these  experts  should  verify 
that  the  recovered  design  and  support  documentation  accurately  portray  the  software  system. 
They  should  also  be  consulted  to  clarify  complex  or  confusing  aspects  of  the  software  system 
throughout  the  reengineering  process. 

Automated  tools,  if  available,  may  be  useful  in  supporting  this  reengineering  strategy. 
The  tool  performance  will  be  impacted  by  several  issues,  including  size  and  complexity.  In 
general,  reengineering  processes  that  are  easy  to  automate  will  be  more  successfid  on  smaller 
software  noodules.  More  manual  efforts  will  be  required  on  larger  modules.  Poor  structure 
may  cause  automated  tools  difficulty  in  analyzing  the  source  code.  It  may  be  advantageous 
for  a  team  of  programmers  to  go  through  the  code  manually  to  identify  such  areas  in  the  code 
and  perhaps  manually  discard  or  modify  them.  Considering  the  focus  of  most  CASE  tools  for 
a  particular  conq)uting  enviroiunent,  one  set  of  CASE  tools  should  not  be  depended  on  for 
uniform  rq)plicability  to  all  software  systems  across  this  organization  [Ruhl91,  p21].  In 
addition,  since  several  tools  may  be  used  during  reengineering,  it  is  important  to  consider  not 
only  the  impact  of  these  tools  on  the  existing  software  engineering  environment  in  the 
organization,  but  whether  or  not  there  is  data  interchange  capability  between  these  tools. 

Good  business  sense  should  be  applied  when  considering  the  purchase  of  expensive  tools. 

The  persotmel  with  the  expertise  on  the  methodologies  and  automated  tools  for  performing  the 
reengineering  activity(s)  should  work  with  the  appropriate  experts  to  match  the  technical 
approach  for  reengineering  with  the  characteristics  of  the  software  system  and  the  desired 
target  system.  If  these  experts  do  not  readily  exist,  die  reengineering  strategy  must 
accommodate  appropriate  training  for  the  methods  and  tools  associated  with  the  reengineering 
strategy  selected. 


S.3  Comparison  of  Strategy  to  Actual  Reengineering  Effort.  The  strategy  proposed  by  the 
Software  Reengineering  Criteria  was  similar  to  one  performed  in  an  actual  reengineering 
effort  [MITR92].  This  effort  involved  a  software  system  similar  to  the  one  suggested  for  a 
first  time  reengineering  effort  in  the  example  organization  above.  The  software  system  was 
typical  of  those  in  the  SEE  according  to  the  size,  languages,  and  usage  criteria.  This  system 
was  120K  source  lines  of  COBOL  and  included  tape  interfaces. 

The  actual  effort  primarily  consisted  of  reverse  engineering  the  logical  data  model 
from  the  COBOL  source  code  and  available  documentation.  The  forward  engineering  process 
has  yet  to  be  complete.^,  but  consists  of  generating  a  new  logical  data  model,  physical  data 
model,  and  new  database  design. 

The  Bachman  COBOL  Capture  and  Data  Analyst  tools  were  used  to  capture  the 
system's  data  requirements.  The  data  structure  and  documentation  criteria  suggest  that 
redocumentation  be  used  to  understand  the  current  structure  of  the  data  and  using  an 
automated  tool  would  speed  the  process  as  suggested  by  the  Methodology  factors.  Reverse 
engineering  was  used  to  capture  the  data  model  and  the  Bachman  toolset  automatically 
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provided  some  of  the  suggested  information  on  the  data  requirements  during  this  process. 

The  technology  insertion  criteria  did  suggest  that  reverse  engineering  the  data  model  and 
integrating  an  efficient  data  management  facility  would  provide  the  biggest  payoff  for  this 
information  system  and  this  was  the  approach  taken  in  the  actual  project. 

The  key  issues  with  respect  to  the  existing  system  were  data  management  and  software 
characteristics.  Data  management  was  not  very  efficient,  utilizing  manual  means.  Improving 
the  data  management  process  was  key  to  improving  the  system,  since  a  large  percentage  of 
the  existing  system  fimctions  centered  on  data  management  (70-80%).  Data  names  were  not 
very  informative,  and  better  naming  conventions  were  desired  in  the  target  system.  The 
COBOL  source  code  had  been  modified  so  often  that  it  was  poorly  structure  as  suggested  by 
the  structural  quality  criteria. 

Technology  support  for  reengineering  to  efficiently  support  data  management  and 
maintenance  was  determined  immature  during  this  reengineering  effort.  Reverse  engineering 
of  COBOL  and  translation  tools  from  COBOL  to  Ada  were  also  viewed  as  limited.  There 
were  delays  in  installing  software  due  to  incomplete  documentation  and  the  limitations  of  the 
tools  which  had  to  be  compensated  for  manually.  These  limitations  are  addressed  by  the 
capability  limitations  criteria  which  was  unknown  prior  to  the  reengineering  effort. 

The  new  hardware  platforms  criteria  determined  that  the  decision  had  been  made  to 
move  to  an  advanced  software  and  hardware  platforms  in  anticipation  that  this  would  also 
improve  the  system.  The  hardware  platform  would  also  improve  data  management  and 
support  the  integration  of  a  commercial  DBMS.  The  target  system  selected  was  a  Unix-based 
AT&T  3B2  computer  and  the  implementation  languages  of  Ada  and  a  fourth  generation 
language  (4GL),  integrated  with  the  Oracle  relational  database.  These  implementation 
decisions  also  supported  the  new  organizational  goal  criteria. 

The  Criteria  recommended  that  automated  tools  should  be  considered,  and  that 
appropriate  training  for  the  methods  and  tools  must  be  incorporated  into  the  schedule.  If 
these  tools  did  not  exist  then  adequate  compensation  for  their  limitations  should  be  made  by 
experienced  persoimel.  The  actual  effort  found  that  available  technology  was  immature  and 
processes  had  to  be  performed  manually.  The  schedule  and  ejfort  estimations  criteria  refer  to 
the  issues  which  must  be  considered  when  establishing  milestones  for  a  reengineering  project, 
which  include  training  and  tool  installation.  This  criteria  warns  that  delays  should  be 
expected  in  utilizing  automated  tools  with  respect  to  training  and  that  adequate  hardware 
platforms  are  necessary  to  support  these  products.  It  was  not  clear  in  this  reengineering  effort 
as  to  whether  reasonable  estimates  and  schedules  were  made,  however  these  issues  resulted  in 
delays  and  execution  problems  for  the  actual  effort. 


5.4  How  Results  Are  Derived.  The  following  explains  how  the  answers  to  the  Software 
Reengineering  Criteria  Questiormaire  in  Section  5.1  determined  the  reengineering  strategy 
presented  in  Section  5.2.  Each  question  in  the  questiormaire  relates  to  a  specific  criteria  that 
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is  highlighted  in  the  text  of  the  question.  The  definition  of  each  criteria  is  obtained  from 
Section  4  and  examined.  This  examination  extracts  the  relevant  text  from  the  definition  based 
on  the  answer  to  the  question.  From  the  relevant  text  references  to  the  application  of  the 
specific  reengineering  capabilities  as  defined  in  Section  2  are  extracted,  then  combined  with 
other  criteria  and  finally  consolidated  to  eliminate  any  redundant  text.  This  text  was  thoi 
consolidated  by  combining  text  which  applied  to  like  reengineering  capabilities.  For  exanq)le, 
all  of  the  criteria  which  implied  reverse  engineering  strategies  was  combined  to  form  the 
reverse  engineering  strategy  presented  in  Section  5.2.  Each  question  and  answer  is  listed 
below  followed  by  the  ^propriate  text  for  each  criteria  from  Section  4. 

What  is  the  complexity  of  the  software?  (identify  those  modules  with  highest  complexity  for 
additional  examination)  average  system  is  estimated  between  10  and  20  using  Cyclomatic 
complexity  method^  between  5  and  10  for  Essential  complexity^ 

The  complexity  criteria  states  that  "Restructuring  the  existing  software  may  lessen  the 
coiiq)lexity  without  altering  the  functionality  of  the  software.  Enq)hasis  should  be  placed  on 
eliminating  goto  statements  and  code  that  is  never  executed.  The  software  can  also  be  reverse 
engineered  to  a  high  level  design  which  is  then  restructured  and  used  to  generate  a  more 
concise  and  efficient  inq)lementation  of  the  software.  The  reverse  engineering  process  must 
be  verified  to  insure  that  the  recovered  design  accurately  captures  the  existing  software.  This 
process  is  preferred  when  there  are  additional  implementation  changes  desired,  such  as 
converting  to  the  Ada  programming  language." 


What  is  the  data  structure  used  in  the  software?  data  design  based  on  physical  components 
of  the  computer  system 

The  criteria  states  that  "Data  design  is  the  key  structural  component  in  most  infonnation 
systems,  requiring  extensive  database  management.  The  largest  percent  of  functionality  in 
most  information  systems  is  performed  within  the  context  of  data  management.  The  data 
architecture  is  often  the  driving  force  behind  the  software  control  flow  architecture.  For  this 
reason,  enq>hasis  should  be  placed  on  the  data  design  because  it  will  force  modifications  to 
the  process  design  [Ruhl91,  pi 7].  Redocumentation  may  provide  insight  into  the  current 
structure  of  the  data,  generating  tables  of  variable  names,  and  identifying  within  the  software 
where  the  data  is  used  and  modified.  Steps  should  be  taken  to  rename  data  to  more 
informative  terms  as  permitted  in  the  current  software  implementation  [MITR92]  and  to 
adhere  to  DOD  standards  concerning  data  naming  conventions.  Reverse  engineering  the  data 
model  and  integrating  an  efficient  data  management  facility  will  provide  the  biggest  payoff 
for  most  information  systems  [MITR92].  Improved  naming  conventions  may  only  be 
achieved  by  reimplementing  in  a  new  programming  language,  such  as  a  language  that  does 
not  limit  variable  name  length  or  characters  that  can  be  used.  Migration  to  advanced 
hardware  platforms  also  can  improve  data  structure  and  naming  conventions  through  increas^*^ 
memory  capacity." 
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What  programming  languages  are  used  to  implement  the  software?  COBOL-74 


The  criteria  states  that  "Translation  is  usually  most  successful  in  efforts  where  the  goal  is  to 
solely  generate  a  new  version  of  the  system  in  another  language  that  is  similar  to  the  current 
language  or  a  different  version  of  the  same  language.  This  effort  is  also  under  time 
constraints  and  is  minimally  funded.  This  strategy  is  most  successful  with  small  programs 
where  the  software  architecture  and  data  structure  will  remain  the  same.  Reverse  engineering 
to  a  language-independent  design  is  an  alternative  to  translation  which  may  be  more  time- 
consuming  and  expensive.  This  design  can  then  be  used  to  generate  a  more  efficient 
representation  of  the  software  which  is  more  efficient,  taking  advantage  of  the  new  language 
constructs.  Translation  does  not  incorporate  alternative  implementations  which  use  the  unique 
features  of  the  target  language.  This  must  be  accomplished  through  manual  conversion  or 
restructuring  techniques." 


What  is  the  size  of  the  software?  (How  many  lines  of  source  code/function  points?)  100-150 
KSLOC  per  software  system  across  multiple  programs 

The  criteria  states  that  "Cost  and  schedule  will  also  be  impacted  by  the  size.  In  general, 
reengineering  processes  that  are  easy  to  automate  will  be  more  successful  on  smaller  software 
nK>dules.  More  manual  efforts  will  be  required  on  larger  modules." 


What  is  the  software  change  rate!  (The  number  of  modifications  made  over  a  given  period  in 
time)  average  of  3  per  month  per  system 

The  criteria  states  that  "Assessments  should  be  made  to  determine  what  the  needs  of  the  user 
are  relative  to  the  functionality  of  the  software.  An  ever-changing  software  system  should  be 
quickly  migrated  to  a  more  efficient  support  environment  to  better  adapt  to  the  needs  of  the 
user.  Unnecessary  functionality  should  be  eliminated,  and  desired  ftmctionality  improved. 
Reverse  engineering  to  a  CASE  environment  can  provide  automated  support  and  is  also  useful 
for  generating  a  more  modem  system." 


What  is  the  software  importance!  (Number  of  times  the  software  is  accessed  in  a  given  period 
of  time;  is  the  software  functionality  life-threatening;  does  the  software  perfonn  some 
function(s)  not  performed  anywhere  else  in  the  organization?)  there  are  several  systems 
that  perform  unique  functions,  loss  of  one  of  these  system  would  be  very  damaging  to 
the  organization 

The  criteria  states  that  "Software  importance  is  determined  by  the  number  of  people  or 
organizations  which  utilize  the  software  system.  Users  of  the  system  also  include  external 
automated  systems  with  which  the  candidate  system  interfaces.  Examples  of  highly  critical 
software  systems  includes  those  that  perform  functions  in  no  other  software  system,  those 
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which  could  not  easily  be  replaced  with  another  system,  and  those  which  would  have  a 
detrimental  effect  on  the  organization  if  they  were  to  be  eliminated.  A  payroll  system  could 
be  considered  a  highly  critical  system,  since  its  elimination  would  have  an  oiormous  impact 
on  the  oiganization  should  the  employees  experience  a  delay  in  their  pay.  If  the  system 
performs  life-threatening  functions  or  unique  functions  which  no  other  system  performs,  then 
the  system  is  also  highly  critical.  Infonnation  dependencies  between  the  candidate  system 
and  external  systems,  as  well  as  other  systems  within  a  like  domain  should  be  identified 
[Ruhl91,  plS].  The  oiganization  should  make  a  determination  as  to  why  the  system  is 
inqwrtant  and  consider  redevelopment  or  reverse  engineering,  while  the  system  remains  in 
use.  This  system  should  probably  be  an  example  system  to  analyze  from  a  functional 
viewpoint  as  a  basis  for  determining  new  technology  that  will  improve  the  overall  current 
business  practices  of  the  oiganization  [Ruhl91,  plS].  The  cost  of  reengineering  these  systems 
should  be  weighed  heavily  against  the  importance  of  its  functions  and  ample  support  should 
be  given  to  inqirove  and  secure  this  type  of  software  system  for  extended  use.  Highly  critical 
systems  should  be  further  examined  for  consolidation  to  minimize  the  number  of  ov^l 
systems  vdiich  the  oiganization  must  support." 


What  is  the  structural  quality  of  the  software?  (Is  there  missing  code  or  "dead"  code  that  is 
never  executed;  is  there  evidence  of  woik-arounds  that  modify  the  software?)  evidence  of 
patches,  poorfy  structured  in  most  cases 

The  criteria  states  that  "Structural  quality  describes  the  structure  or  architecture'  of  the 
software  system.  The  software  architecture  may  be  well-structured  and  suitable  for  quickly 
converting  to  a  modem  programming  language  or  hardware  platform.  In  this  case,  translation 
can  be  an  effective  means  for  performing  this  conversion.  Poorly  stmctured  software  is  a 
candidate  for  code  restmcturing  or  for  reverse  engineering  to  produce  a  design  representation 
that  can  then  be  restructured  [MITR92].  Poor  stracture  may  cause  automated  tools  difficulty 
in  aiuilyzing  the  source  code.  Time  may  be  wasted  on  analyzing  and  reverse  engineering 
dead  code  that  is  of  no  value  to  the  system  requirements.  It  may  be  advantageous  for  a  team 
of  programmers  examine  the  code  manually  to  identify  such  areas  in  the  code  and  perhaps 
manually  discard  or  modify  them.  Redocumentation  techniques  can  often  report  on  the 
stractural  quality  of  source  code.  Automated  redocumentation  exists  that  generates  stmcture 
charts^  which  define  the  procedures  used  to  implement  the  software,  including  the  calling 
hierarchy,  naming  conventions,  and  input  and  output  of  data  between  these  modules.  This  is 
useful  in  quickly  identifying  modules  which  are  never  executed,  are  not  represented  in  an 
existing  high  level  design,  or  utilize  global  data  [STSC92]." 


^Architecture  Includes  the  In^^lementatlon  design  of  the  software.  The 
term  Design  Is  used  to  define  a  criteria  under  Development  Factors  that  refers 
to  the  existence  of  a  high-level  representation  of  the  software. 

^Structure  charts  depict  the  structure  of  the  software  as 
defined  by  Edward  Yourdon  and  Larry  Constantine  in  Structured 
Design.  Englewood  Cliffs,  N J :  Prentice  Hall,  1979. 
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Are  there  alternate  configurations  of  the  software  and  what  are  the  conditions  for  which  these 
exist?  no 

The  criteria  states  that  "Alternate  configurations  idoitifies  whether  or  not  there  are  alternate 
configuratitnis  of  the  software  system.  The  requirements  justifying  these  versions  should  be 
identified  and  it  should  be  detomined  whether  the  alternate  config;urations  can  be 
consolidated  into  a  single  software  system.  Restructuring  the  system  may  improve  modularity 
for  identifying  specific  functions  and  enable  a  system  to  incorporate  functions  previously 
performed  in  otha*  systems.  Reverse  engineering  permits  the  consolidation  of  these  functions 
into  a  uniform  design  representation  that  can  then  be  used  to  generate  the  new  software 
system." 


What  commercial  software  interface  does  the  system  contain?  (e.g.,  DBMS  and  X-Windows) 
none 

The  criteria  states  that  "Commercial  software  interface  describes  the  number  of  commercial 
software  packages  that  interface  the  software  system.  It  is  important  to  identify  all  of  these 
interfaces  and  understand  the  structure  of  this  interface  to  insure  that  any  reiiiq>lementation  or 
modification  to  the  existing  software  maintains  this  intersection.  Poorly  integrated  system 
conq)onents  is  a  reason  to  consider  reengineering  [MITR92].  Most  modernization  efforts 
integrate  commercially  available  software  components,  including  database  maitagement 
systems  (DBMS)  and  other  software  packages  to  meet  system  requirements.  The  key  issue 
in  most  of  these  integration  efforts  is  the  data  interchange  format.  Commercial  packages  do 
not  easily  interact  with  older  programming  languages  of  hardware  platforms,  thus  requiring 
conversion  to  new  software  and  hardware  implementations.  Reverse  engineering  the  software 
to  a  design  representation  provides  a  means  for  achieving  this  type  of  conversion.  The  design 
can  be  restructured  to  better  integrate  commercially  available  system  components  and 
reimplemented  in  modem  programming  languages  for  state  of  the  art  hardware." 


Are  existing  requirements  obsolete  or  need  change?  not  at  this  time 

The  criteria  states  that  "Requirement  obsolescence  describes  to  what  degree  the  system 
requirements  are  no  longer  viable.  Current  system  functionality  may  not  conform  to  user 
needs.  Obsolete  requirements  should  be  eliminated  from  the  existing  system  during 
reengineeiing.  Source  code  which  performs  these  requirements  should  be  extracted  from  the 
software  prior  to  restmcturing  if  possible,  else  afterwards.  Reverse  engineering  to  the  design 
level  may  more  easily  identify  the  portions  of  the  software  performing  these  outdated 
requirements  and  can  easily  be  removed  from  the  design  prior  to  reimplementation." 
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Are  there  domain  consistencies  which  must  be  maintained  by  this  system?  no 


The  criteria  states  that  "Domain  consistency  describes  whether  or  not  the  system  exists  within 
a  domain  and  the  description  of  that  domain.  Modifications  to  the  system  must  conform 
within  the  constraints  of  this  domain.  Often  reverse  engineering  is  performed  to  migrate  a 
software  system  to  a  domain  that  provides  consistency  across  similar  applications  in  an 
organization.  ReimplementatitHi  of  the  new  system  should  consider  reuse  options  for 
achieving  domain  consistency  as  well  as  consolidation  of  functionality  across  multiple 
software  systems." 


What  is  the  hardware  interface  for  this  software  system?  (Is  there  a  strong  relationship 
between  hardware  and  software?  Is  the  current  software  portable  to  other  hardware 
platforms?)  Honeywell  DPS-8000  computer,  software  Is  not  portable 

The  criteria  states  that  "Hardware  interface  describes  the  current  hardware  platform  upon 
which  the  software  system  executes  and  a  description  of  the  dependencies  of  the  software  on 
this  platfmm.  The  hardware  capabilities  often  restrict  software  implementation  options  and 
these  may  change  given  an  alternative  platform.  Antiquated  hardware  is  often  the  reason  for 
modernizing  the  software  system  [MITRE92].  Fewo*  dependencies  may  ease  migration  to  a 
new  hardware  amfiguration,  while  strong  ties  may  impact  the  technical  approach  taken  to 
modernize  the  software.  Reverse  engineering  is  useful  for  generating  a  hardware-independent 
design  of  die  software  and  determining  urplementation  dependencies  which  resulted  from  that 
platform.  The  hardware-independent  design  can  then  be  implemented  for  alternate  hardware 
configurations." 


What  is  the  usage  of  this  software?  How  many  users  are  there  for  this  system?  How  many 
individuals,  oiganizations,  or  automated  systems  use  this  system?)  tape  interface  with 
several  external  software  systems;  tape  interface  with  several  deWces,  including  HP 
1000-A  minicomputer  and  a  NCS  Westinghouse  Scanner;  ^stem  is  on-line 

The  criteria  states  that  "Usage  describes  the  amount  of  use  the  software  system  undergoes, 
including  the  number  and  type  of  interactions  with  the  system  by  individuals,  external 
organizations  and  other  automated  systems.  The  needs  of  these  entities  must  be  maintained 
when  modernizing  the  system.  In  many  cases  it  is  precisely  these  needs  diat  are  driving  the 
reengineering  effort.  Modernizing  the  system  promises  to  improve  response  times  by  the 
system  as  well  as  by  maintainers  responding  to  change  requests  from  the  users.  Reverse 
engineering  to  an  automated  support  environment  helps  improve  the  modification  process. 
Redocumentation  provides  supporting  documentation  to  maintainers  making  decisions  about 
modifications.  Restracturing  the  software  may  enable  the  system  to  more  readily  accept 
modifications  without  negatively  impacting 
other  parts  of  the  system." 
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Does  a  high  level  design  of  this  software  exist?  (Is  the  available  design  complete  with  respect 
to  the  current  software?  Is  the  available  design  consistent  with  respect  to  the  current 
software?)  data  requirements  for  each  system  existed  when  it  was  buiit,  but  were  never 
documented. 

The  criteria  states  that  "Design  is  a  comprehensive  high  level  representation  of  the  softvrare 
that  is  consistent  and  ctnnplete  to  the  current  implementation.  If  this  representation  exists,  it 
may  be  used  or  restructured  to  reimplement  the  software  in  a  standard  development  process. 
If  Ae  existing  design  is  not  consistent  or  complete,  it  may  be  used  as  supplemental 
documentation  during  a  reverse  engineering  process  which  will  produce  a  nK>re 
coiiq)rehensive  and  current  representation.  Reverse  engineering  is  used  to  generate  designs 
for  software  systems  that  do  not  have  an  available  design  that  is  complete  or  consistent  with 
the  current  implementation  of  the  software  system  that  is  useable  in  a  effective  maintenance 
process.  This  may  include  designs  that  were  not  originally  developed  using  structured 
modeling  techniques  or  are  not  supported  by  an  automated  process  (automation  provides 
necessary  efficient  maintenance  support)  [McCa92].  The  design  may  serve  as  an  end  product 
that  provides  system  understanding  or  may  serve  as  a  means  for  implementing  a  new  system 
with  added  functionality  or  new  programming  language.  Reverse  engineering  the  data  model 
for  information  systems  often  lends  insight  into  how  to  restructure  the  data  for  an  improved 
implementation." 


What  development  methodology  was  followed?  (Were  structured  methodologies  or  some  type 
of  well-defined  and  documented  methodology  utilized?)  no  standard  procedure 

The  criteria  states  that  "Development  methodology  identifies  whether  or  not  a  well-defined 
development  procedwe  was  used  in  developing  this  software.  If  a  docmnented  methodology 
was  used,  then  it  may  be  easier  to  understand  the  impact  of  this  methodology  on  the 
implementation  of  the  software  and  the  design  of  the  software,  if  it  exists.  It  is  also  important 
to  note  if  automation  was  used  in  developing  the  software  system.  If  the  previous 
development  procedure  is  still  a  viable  development  methodology,  then  consideration  should 
be  given  for  utilizing  this  method  in  regenerating  the  software  system." 


What  supporting  documentation  exists?  very  little 

The  criteria  states  that  "Documentation  describes  any  reports,  tables,  or  design  record  that 
exists  for  the  software  system.  Documentation  is  credited  with  being  the  key  to  adequate 
software  maintenance,  and  yet  it  is  still  the  most  unqualified  segment  of  the  software 
engineering  process.  As  the  languages  with  which  software  systems  are  implemented  move  to 
lower  abstraction,  the  importance  of  creating  adequate  documentation  becomes  more  critical. 

There  are  useful  suggestions  that  can  be  performed  immediately  to  improve  the 
documentation  status  of  a  software  system  [Hova92].  Obsolete  documents,  such  as  those  that 
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have  not  been  used  in  more  than  a  year,  should  be  discarded  since  they  are  either  outdated  or 
imusable.  Perform  a  documentation  audit  to  determine  what  documents  are  needed  and  set 
about  generating  these  documents  or  making  additions  to  existing  incomplete  documents. 

This  can  be  performed  by  examining  trouble  reports  that  were  diagnosed  as  help  requests,  or 
the  user  help  requests,  if  these  are  logged.  Finely,  new  development,  as  well,  as 
reengineering  should  establish  documentation  as  a  top  priority  in  these  processes.  A  lack  of 
adequate  documentation  is  the  most  common  reason  for  considering  reengineering  [Ruhl91]. 
Redocumentation  techniques  produce  various  types  of  documents  to  supplement  the  software 
system  implementations  (specification,  design,  source  code).  Reports  defining  the  variables, 
procedtue  calls,  and  procedure  interfaces  can  be  useful  in  gaining  a  better  understanding  of 
the  software.  Documentation  supports  reverse  engineering  by  providing  supplemental 
information  that  is  useful  in  distinguishing  design  and  requirements  information  from 
implementation  idiosyncracies." 


Is  the  maintenance  process  supported  by  automation!  no  automation,  manual  data 
management  facilities 

The  criteria  states  that  "Automation  factor  identifies  whether  or  not  an  automated  process  is 
used  for  supporting  the  existing  system  configuration.  Incorporating  automation  is  usually  a 
high  level  goal  of  most  organization  since  it  can  increase  thf^  efficiency  of  many  processes, 
including  development  and  maintenance  [Room92].  Automated  tools  can  assist  the 
mainteiumce  process,  including  language  sensitive  editors  for  performing  source  code 
noodifications  and  automated  configuration  management  to  provide  version  control  and 
document  the  changes  made  to  the  software.  Preparation  for  maintenance  can  begin  in  the 
development  processing  Computer-aided  software  engineering  (CASE)  tools  which  can  be 
used  to  design  and  develop  software,  and  then  maintain  it.  Redocumentation  is  the  most 
mature  automation  capability.  Redocumenting  the  software  using  an  automated  tool  can 
provide  fast  information  about  the  source  code  architecture.  Reverse  engineering  the  software 
into  a  CASE  tool  can  integrate  automation  into  the  maintenance  process." 


What  is  the  improvement  status  of  the  software?  (Is  the  system  status  regarded  as  one  of 
improvement  or  decline?  Is  the  ciurent  system  defective?)  maintenance  back-log  which  is 
increasing  for  at  least  one  system,  ever-increasing  user  demands  mean  there  are  several 
systems  that  are  becoming  outdated,  system  quality  is  relatively  remaining  the  same 

The  criteria  states  that  "Improvement  status  identifies  to  what  extent  the  system  is  operating 
according  to  the  current  system  requirements  There  are  several  methods  for  measuring  faults 
in  source  code,  including  Gaffney^.  If  there  are  current  defects  in  the  software  or 


^Gaffney,  John  E.,  "Estimating  the  Number  of  Faults  In  Code,"  IEEE 
Transactions  on  Software  Engineering,  vol  SE-10,  no.  4,  July  1984,  pp.  459- 
465. 
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modifications  that  have  been  requested  which  have  not  been  implemented,  either  due  to 
modification  effort  or  cost,  this  may  be  a  good  time  to  consider  reengineering  options.  An 
analysis  of  the  system  may  identify  isolated  parts  of  the  software  which  are  not  performing 
adequately.  These  parts  may  be  reverse  engineered,  modified  at  the  design  level,  and 
reimplemented.  The  corrected  parts  can  then  be  integrated  back  into  the  remaining  software. 
Most  existing  source  code  components  are  so  tightly  interweaved,  that  it  is  usually  necessary 
to  reverse  engineer  the  entire  software  system  and  generate  a  more  modular  software  system. 

This  criteria  also  identifies  to  what  degree  the  system  could  be  improved  to  meet 
current  known  requirements  efficiently.  If  the  system  has  many  modifications  that  are 
necessary  in  order  for  it  to  reach  an  acceptable  level  of  performance,  then  consideration 
should  be  given  for  whether  this  software  should  continue  as  a  fimctioning  element  in  the 
organization.  It  should  be  clearly  imderstood  what  changes  are  necessary  and  incorporate 
those  into  a  reengineering  process.  Restmcturing  can  be  applied  to  improve  the  performance 
of  the  software  without  introducing  new  functionality.  Reverse  engineering  can  be  used  to 
abstract  a  high  level  design  which  could  then  be  used  to  incorporate  new  fonctionality  that  is 
implemented  in  a  new  software  system." 


What  is  the  life  expectancy  of  this  system?  How  long  is  this  system  expected  to  operate? 
indefinite,  the  functionaUty  of  these  systems  wiU  be  continuously  required 

The  criteria  states  that  "Life  expectancy  identifies  the  number  of  years  this  software  system  is 
expected  to  remain  in  operation.  The  system  may  not  be  operating  much  longer  because  the 
functions  are  becoming  outdated  or  because  the  software  system  has  been  designated  for 
replacement.  If  the  software  is  not  expected  to  be  in  use  much  longer  due  to  functional 
obsolescence,  only  improvements  to  the  current  maintenance  process  should  be  considered.  If 
the  software  has  been  designated  for  replacement,  certain  reengineering  capabilities  are 
feasible.  Only  available  resources  shoidd  be  applied,  including  automated  tools  which 
currently  exist  in  the  organization.  Minimal  redocumentation  and  restructuring  should  be 
performed  to  provide  quick  benefits  for  improving  maintenance  and  extending  the  life  of  the 
system  to  insure  it  remains  operational  until  replacement  can  be  made.  Advanced  processes 
within  these  capabilities  and  reverse  engineering  should  be  considered  only  if  the  option  of 
replacing  the  system  can  be  upheld  by  revitalizing  the  existing  one  through  reengineering." 


What  is  the  modification  efford  (How  many  labor  hours  are  spent  modifying  the  system?) 
more  than  32  hours  per  month  average,  maintainers  have  expressed  general  difficulty  in 
making  software  changes 

The  criteria  states  that  "Modification  effort  identifies  the  rate  of  modification  over  number  of 
modifications  times  the  average  number  of  maintainers  to  complete.  If  the  existing  software 
is  very  difficult  to  maintain,  tiiis  may  be  a  sign  that  it  needs  to  be  reengineered.  The  software 
maintainers  should  be  interviewed  to  determine  if  the  difficulties  are  due  to  a  lack  of 
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understanding,  complexity  of  the  software,  result  in  "rippling  effect"  that  leads  to  more 
problems. 

A  lack  of  software  understanding  may  be  minimized  through  improved  supporting 
documentation.  Redocumenting  the  software  may  identify  inteireladonships  between  the 
software  con^xments  that  are  impacted  during  maintenance  procedures,  lliis  can  be  useful 
when  modifying  software  for  predicting  effects  of  change  on  other  parts  of  the  software. 
Restructuring  the  software  may  reduce  its  complexity,  and  eliminate  unnecessary  code.  Both 
of  these  techniques  may  reduce  the  chances  that  one  modification  to  the  software  may  have  a 
disastrous  effect  on  other  parts  of  the  software.  Severe  problems  may  only  be  solved  through 
reverse  engineering  and  a  complete  regeneration  of  the  software  system." 


Is  there  a  desire  to  migrate  to  another  language'!  Ada  and  4GL 

The  criteria  states  that  "Language  migration  describes  the  identification  and  description  of  the 
language  iiiq)lementation  requested  for  this  system.  There  are  several  reasons  for 
reimplementing  the  software  in  a  different  programming  language,  including  implementation 
improvements  offered  by  the  language  or  the  desire  to  implement  all  software  in  a  common 
language  within  an  organization  to  ease  maintenance.  Within  DOD,  the  standard 
programming  language  selected  is  Ada.  Most  modernization  efforts  within  DOD  are  required 
to  use  Ada.  Reengineering  the  existing  software  to  Ada  is  one  way  to  adhere  to  this  mandate. 
If  the  current  language  implementation  is  similar  to  Ada,  translation  can  be  performed  to  the 
new  implementation  and  if  necessary  manual  code  generation  for  the  software  which  does  not 
easily  convert  Reverse  engineering  to  a  high  level  design  and  then  regenerating  the  software 
in  Ada  is  another  option.  Often  the  existing  system  implementation  is  used  as  the  baseline,  a 
design,  or  supporting  documentation  which  is  referenced  when  generating  a  new  software 
system  in  the  target  language  manually.  This  may  prove  to  be  the  most  time-consuming 
effort." 


Will  the  performance  of  the  system  be  improved!  (Will  new  performance  requirements  be 
introduce?)  better  response  to  user  requests  is  needed 

The  criteria  states  that  "Performance  improvement  describes  the  identification  and  description 
of  the  desired  performance  improvements  for  this  system.  These  improvements  may  be 
achievable  in  the  existing  software  implementation,  and  this  should  considered.  Although, 
more  often  these  performance  requirements  require  improved  hardware  or  new  software 
implementation,  i^mproving  the  performance  of  the  software  may  be  an  opportunity  to 
reengineer  to  a  new  system  implementation.  Translation  to  a  new  software  language  for 
execution  on  a  new  hardware  platform  is  one  of  the  fastest  migration  techniques,  however  the 
translated  software  may  not  utilize  the  capabilities  of  the  target  language  or  the  new  hardware. 
Reverse  engineering  to  a  high  level  design  which  can  then  be  targeted  for  a  new  hardware 
suite  is  one  way  to  achieve  these  performance  improvements." 
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Can  technology  insertion  improve  the  software  system?  Are  new  technologies  available  that 
would  greatly  improve  system  implementation?  yes,  DBMS 


The  criteria  states  that  "Technology  insertion  is  the  identification  of  specific  technological 
advances  that  could  improve  the  implementation  of  the  software.  This  criteria  does  not 
include  automated  support  for  the  development  or  maintenance  of  software,  which  is  defined 
in  New  Support  Characteristics.  The  awareness  of  new  technology  that  may  support  the 
existing  functionality  of  the  current  software  system  or  new  requirements  that  are  to  be 
incorporated  into  the  existing  system,  may  be  performed  throu^  reengineering  [MrrR£92]. 
Reusable  components  may  be  incorporated  into  the  existing  system  to  replace  outdated 
components  and  improve  the  performance  of  the  software.  Often  improved  data  management 
facilities  may  be  incorporated  into  an  information  system  which  previously  performed  its  data 
management  in  an  ad-hoc  or  hard-coded  manner.  Reverse  engineering  the  data  models  from 
the  software  and  incorporating  a  commercial  database  may  improve  data  management.  New 
programming  languages  may  be  used  to  implement  a  software  system  that  contains  improved 
library  routines,  functions  and  data  structures  that  better  support  the  system  requirements. 
Reverse  engineering  can  salvage  an  existing  software  design,  which  can  then  be  restructured 
and  reimplemented  into  a  more  modem  software  system  that  utilizes  advanced  software 
engineering  technology." 


Is  the  goal  to  make  the  system  adaptable!  yes  (future  migrations  are  anticipated  for  each 
system) 

The  criteria  states  that  "Adaptability  describes  to  what  extent  the  new  support  enviromnent 
will  enable  the  software  system  to  adapt  to  a  changing  environment,  i.e.,  enhancements, 
alternate  software/hardware  implementations,  integration  of  new  components.  These 
characteristics  will  prepare  the  software  system  for  future  migrations.  Reengineering  is  often 
used  to  modernize  the  software  to  a  implementation  that  is  better  suited  for  future  migrations 
[MITRE92].  Restructuring  the  data  model  and  software  architecture  may  better  prepare  the 
software  for  future  modifications.  Reverse  engineering  the  software  into  a  CASE  tool  may 
facilitate  the  generation  of  implementations  in  alternative  languages.  Eliminating  hardware 
dependencies  when  using  the  recovered  design  in  a  new  implementation  may  make  the 
software  more  portable  for  future  migrations  to  new  or  alternative  hardware  platforms." 


Is  there  a  desire  to  automate  the  maintenance  process?  yes 

The  criteria  states  that  "Automation  insertion  describes  the  automated  techniques  that  are 
needed  to  support  the  new  support  environment.  This  criteria  does  not  include 
implementation  techniques  supplied  by  technological  advances  software  development,  which 
was  addressed  in  Target  Software  Characteristics.  The  desire  to  automate  the  maintenance 
environment  is  often  the  reason  for  modernizing  a  software  system  [MITRE92].  CASE  tools 
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which  are  used  to  develop  software  systems  are  useful  throughout  the  life  of  the  software  by 
supporting  modifications  to  the  source  code  while  updating  designs  and  documentation. 

Steps  can  be  taken  to  integrate  CASE  into  the  existing  software  engineering 
environment  within  an  organization  [CIM92].  This  is  most  often  successful  in  more  modem 
software  systems  and  mature  organizations.  Many  programming  languages  and  oldo* 
hardware  platforms  do  not  support  modem  CASE  tools,  thus  forcing  the  modernization  of  the 
software  system  itself.  Reverse  engineering  provides  a  means  for  extracting  information  and 
populating  CASE  repositories  with  data  that  can  be  used  to  support  the  current 
implementation.  CASE  often  includes  code  generation  support  for  reimplementing  the 
software  into  a  more  modem  programming  language." 


Is  the  goal  to  make  the  system  domain  consistent!  migrate  these  systems  towards 
DISA/CIM  information  systems  domain 

The  criteria  states  that  "Domain  consistency  describes  to  what  extent  the  new  support 
environment  supports  other  systems  in  the  same  domain.  Systems  that  reside  in  a  identifiable 
domain  should  be  considered  for  reengineering  for  achieving  commonality  through  software 
reuse  and  consolidation.  Redocumentation  techniques  can  be  used  to  identify  commonality 
between  software  systems.  Software  system  should  be  consolidated  where  possible.  Reverse 
engineering  systems  within  a  single  domain  can  enable  the  generation  of  a  consolidated 
system  from  separate  software  programs  implemented  in  vaiying  languages  and  executing  on 
(fiffering  hardware  platforms.  Reuse  modules  should  be  used  to  implement  common 
functionality  when  possible." 


Is  there  a  desire  to  improve  the  maintenance  process  or  change  to  a  new  or  different 
automated  support  environment?  yes,  current  maintenance  organization  is  declining:  there 
is  a  need  to  reduce  current  maintenance  costs,  improve  data  management,  and  ease 
modification  effort 

The  criteria  states  that  "Maintainability  describes  to  what  extent  the  new  support  environment 
provides  improvements  to  the  overall  maintenance  process.  This  identifies  specific 
technological  advances  that  are  a  part  of  the  new  support  environment  that  improve  the 
process  of  supporting  the  system  software  and  a  description  of  how  this  is  accomplished.  The 
integration  of  CASE  tools  promises  to  enable  faster  modifications  to  the  software  and 
automatic  updates  to  supporting  documentation.  Reverse  engineering  is  used  to  produce  a 
high  level  design  representation  that  can  be  stored  and  automatically  supported  within  a 
CASE  tool.  The  ability  to  make  changes  and  generate  updates  to  this  representation  and 
subsequently  the  implementation,  should  improve  response  time  to  change  requests." 
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Are  there  domain  consistencies  which  must  be  maintained  by  this  system?  none  at  this  time 


The  criteria  states  that  "Domain  integration  is  the  identification  and  description  of  the  new 
target  domain.  The  domain  may  be  the  programming  language,  hardware  platform,  or 
functional.  Domains  from  which  the  current  system  is  far  removed  may  be  more  difficult  to 
reach  through  reengineering  and  may  require  a  completed  redevelopment.  A  well-structured 
and  nKxiular  software  system  may  incorporate  replacement  parts  that  are  reuse  software 
modules  that  immediately  migrate  the  existing  system  to  a  desired  domain." 


Initially,  is  there  a  desire  to  move  to  another/multiple  new  hardware  platformsl  yes,  AT&T 
B32  processor  and  others,  all  running  Unix 

The  criteria  states  that  "New  hardware  platforms  is  the  identification  and  description  of 
alternative  or  new  hardware  platforms.  An  understanding  of  the  new  hardware  platform  and 
how  the  current  software  int^aces  with  is  crucial  to  the  success  of  the  system  migration. 

This  describes  the  number  and  type  of  hardware  interfaces  which  are  to  be  integrated  to  this 
system.  The  new  hardware  platform  often  drives  the  modification  of  the  software  to  a  new  or 
alternate  version.  It  may  be  necessary  to  restructure  or  update  the  version  of  the  current 
implementation  language  to  execute  die  software  on  the  new  hardware.  Restmcturing  may  be 
necessary,  and  replacement  of  new  library  modules  to  accomplish  the  same  fimctionality  of 
the  existing  software.  This  is  also  a  time  to  consider  an  alternate  implementation  of  the 
software  in  another  programming  language  that  is  more  compatible  with  the  hardware  and 
operating  system.  Reverse  engineering  and  regenwation  of  Ae  software  may  be  useful  in 
generating  a  new  software  system  for  the  new  hardware." 


Is  there  a  new  organizational  goal  to  which  this  software  system  must  adhere?  prepare  for 
future  integration  with  DISA/CIM  information  systems,  need  to  better  express  the  data 
requirements  of  the  business  environment 

The  criteria  states  that  "New  organizational  goals  describes  any  new  organizational  goal(s) 
that  must  be  addressed  by  this  software  system.  Room  presented  high  level  goals  of  an 
organization  which  eliminate  non-essential  products  and  processes,  increase  the  value  of  those 
remaining;  and  increase  the  efficiency  of  those  processes  through  streamlining,  simplification 
and/or  automation  [Room92].  The  organization  may  consider  die  candidate  software  system 
as  non-essential  and  in  this  case  the  best  option  is  to  eliminate  this  software  system.  More 
likely,  this  software  offers  some  value  and  should  be  examined  for  potential  consolidation 
with  other  similar  systems  for  consolidation  purposes  that  will  streamline  and  simplify 
maintenance.  Automation  may  also  be  incorporated  as  discussed  in  paragraph  S.2.1.2  New 
Support  Characteristics  and  5.2.2.2  Methodology  Factors  criteria  below." 


Is  there  automation  support  for  the  methodology  selected?  Bachman  COBOL  Capture  and 
Data  Analyst  tools 


The  criteria  states  that  "Automated  support  identifies  the  automated  tools  which  support  the 
reengineeting  methodology.  There  are  several  tools  available  which  support  various 
reengineering  activities  [STSC92].  It  is  in^wrtant  to  be  realistic  in  what  these  tools  provide. 
Investigate  their  capabilities  and  be  prepar«l  to  address  inefficiencies  through  adequate 
persmmel  who  are  knowledgeable  of  these  tools  and  can  perform  processes  when  the  tools  do 
not  Considering  the  focus  of  most  CASE  tools  for  a  particular  computing  environment,  one 
set  of  CASE  tools  should  not  be  depended  on  for  uniform  applicability  to  all  needs  across  an 
organization  [Ruhl91,  p21].  In  addition,  since  several  tools  may  be  used  during 
reengineering,  it  is  inqMrtant  to  consider  not  only  the  impact  of  these  tools  on  the  existing 
software  engineering  environment  in  the  organization,  but  whether  or  not  there  is  data 
interchange  capability.  Good  business  sense  should  be  applied  when  considering  the  purchase 
of  expensive  tools." 


Does  the  methodology  selected  link  to  the  forward  engineering  environment?  DOD-STD- 
2167A  \ii111  be  followed 

The  criteria  states  that  "Forward  engineering  support  identifies  to  what  extent  the 
reengineeting  tools  support  the  forward  engineering  processes;  identification  and  description 
of  the  interfaces  to  these  processes." 


Has  a  methodology  for  reengineering  this  system  already  been  selected!  reverse  engineering 
and  forward  engineering 

The  criteria  states  that  "Methodology  selected  identifies  a  well-defined  methodology;  insures 
training  is  available  and  that  the  methodology  meets  the  goals  of  the  organization.  A 
methodology  should  be  chosen  that  is  compatible  to  the  requirements  of  the  organization  and 
are  support^  by  automation  where  possible  [Ruhl91,  p21].  It  is  cost-effective  if  this 
methodology  is  usable  across  domains  and  transitions  the  system  to  a  better  maintenance 
process." 


Is  there  reengineering  hardware  platform  available  to  support  tools,  system  data,  and  the 
reengineering  process?  Dec  SlOOAJltrix,  Personal  Computers 

The  criteria  states  that  "Platform  support  identifies  the  hardware/operating  systems  and 
integration  to  existing  or  selected  reengineering  platform  environment;  the  platforms 
supporting  tools  and  the  limitations  of  this  support." 
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Are  these  tools  available  in  the  (»ganization  currently  or  will  they  have  to  be  procured?  some 
currently  available,  but  were  procured  for  this  effort 

The  criteria  states  that  H'ool  availability  identifies  whether  the  tool  currently  exists  in  the 
organization,  is  the  organization  capable  of  acquiring  this  tool,  understanding  the  cost  and 
time  for  procurement." 


Are  there  persoimel  available  who  have  existing  system  expertise  in  the  operatioiis,  functions, 
and  pofotmance  of  the  software  system  and  are  available  to  work  on  the  reengineermg  effort? 
yes:  it  is  understood  that  expert  domain  knowledge  is  imperative  to  capturing  the 
domain  knowledge  and  at  some  of  the  systems  have  experts  available  to  form  redesign 
groups 

The  critoria  states  that  "Existing  system  expertise  identifies  the  personnel  with  the  expertise 
on  the  existing  system.  During  reverse  engineering  and  redocumentation,  these  experts  should 
verify  that  the  recovered  design  and  support  documentation  accurately  portray  the  software 
system.  They  should  also  be  consulted  to  clarify  complex  or  confusing  aspects  of  the 
software  system  throughout  the  reengineering  process.  During  restructuring  these  individuals 
should  be  used  to  verify  that  this  process  is  not  altering  the  functionality  of  the  software 
system  (during  restructuring,  existing  and  target  system  expertise  are  usually  the  same 
individuals  since  only  the  performance  aspects  of  the  system  are  altered  and  functionality 
remains  the  same)." 


Are  there  personnel  available  who  have  target  system  ejq)ertise  in  the  operations,  functions, 
and  performance  of  the  target  software  system  and  are  available  to  work  on  the  reengineering 
effort?  yes:  Redesign  groups,  contractors,  and  DISA/CIM 

The  criteria  states  that  "Target  system  expertise  identifies  persoimel  who  possess  the  expertise 
on  the  desired  target  system.  These  individuals  should  verify  new  requirements  for  achieving 
the  target  system  and  should  be  consulted  to  clarify  any  confusing  aspect  of  the  proposed 
target  system.  During  forward  engineering  these  individuals  should  be  consulted  to  insm-e  the 
new  system  meets  all  requirements,  including  functional  and  performance.  During 
restructuring,  these  individuals  insure  that  performance  has  b^  improved." 


Are  there  persoimel  who  have  reengineering  expertise  and  are  familiar  with  the  selected 
tools?  some:  training  is  required  for  specific  toois;  contractors  and  DISA/CIM  have 
reengineering  experience 

The  criteria  states  that  "Reengineering  expertise  identifies  whether  the  personnel  exist  with  the 
expertise  on  the  methodologies  and  automated  tools  for  performing  the  reengineering 
activity(s).  These  individuals  should  work  with  the  appropriate  experts  to  match  the  technical 
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approach  for  reengineering  with  the  characteristics  of  the  software  system  and  the  desired 
target  system.  Jf  these  experts  are  not  available,  the  reengineering  strategy  must  supply 
appropriate  training  for  the  methods  and  tools  associated  with  the  reengineering  strategy.  " 
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